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Abstract 

I have designed and implemented a system for the multilevel verification of 
synchronous MOS VLSI circuits. The system, called Silica Pithecus, accepts the 

oeha^of S I'" 11 ™ ClfC f ^ " *•**»*» of th « Quit's intended digital 
behavior Silica Pi hecus determines if the circuit meets its specification. If the 

for Z f ? T V? Sp ^. ification Silica Pith «^ ^urns to the designer the reason 
for the failure. Unlike earlier verifiers which modelled primitives (e.g., transistors) 
a. unidirectional digital devices, Silica Pithecus models primitives more realistically 
Transistors are modelled as bidirectional devices of varying resistances, and nodi 

zz^Zir citors ' Silica Pithecus operatea hierarchicaiiy ' interactiveiy > 

Major contributions of this research include a formal understanding of the rela- 
fconship between different behavioral descriptions (e.g., signal, boolean, and arith- 
metic descriptions) of the same device, and a formalization of the relationship be- 
ween the structure behavior, and context of a device. Given these formal struc- 
tures my methods find sufficient conditions on the inputs of circuits which guar- 
antee the correct operation of the circuit in the desired descriptive domain. These 
methods are algorithmic and complete. They also handle complex phenomena such 
as races and charge sharing. Informal notions such as races and hazards are shown 
to be derivable from the correctness conditions used by my methods. 

Thesis Supervisor: Dr. Gerald Jay Sussman 

Title: Professor of Electrical Engineering and Computer Science 
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Chapter 1 
Introduction 



This research is both about verification of synchronous MOS digital circuits, and 
about a particular program, called Silica Pithecus, which is an implementation of 
some of the ideas in this thesis. Verification of digital circuits is a new, not yet 
well understood field. Its development is critical to building larger provably correct 
circuits The field is new enough that what verification is, what it means to verify 
a digital circuit, and how to verify a digital circuit are all largely unanswered (and 
sometimes unasked) questions. The goal of this research is to answer these ques- 
tions. Among the issues that must be addressed are: describing digital systems 
choosing appropriate electrical models, understanding how verification affects the 
design process, relating simulation and verification, understanding the role of ab- 
straction, and relating structure, context, and function. 

This dissertation concerns multilevel verification and signal behavior generation 
Circuit behavior can be described at different levels of abstraction ranging from the 
analog level to the functional level (Figure 1.1). Multilevel verification proves that 
two different levels of behavioral description describe the same behavior. The higher 
(i.e., more abstract) level description of a design's behavior is called its abstract 
behavior, the lower level description of a design's behavior is called its concrete 
behavior. The proof has two parts: abstracting the concrete behavior to the same 
domain as the abstract behavior, and then proving the abstracted behavior and the 
abstract behavioral description are equivalent. 

The signal descriptive level and the digital descriptive level are the two descrip- 
tive levels we will primarily investigate. A signal is a time-varying voltage. The 
primitives operators of the signal level are transistors. A digital value is either 1 
0, or float. The primitive digital operators are AND, OR, NOT, and join. The digital 
descriptive level is time free and functional. It has no time delays or switching 
elements. This allows a digital behavior to be specified as simple combinations of 
primitives. 1 

1 We will use the term "hardware digital level- to refer to a digital description which incorporates 

17 
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CHAPTER l . INTR OD UCTION 




=EH>^ 



C = A OR B 



Signal Level 



Boolean Level Functional Level 



Figure 1.1: An example of multiple levels of behavioral description. Each descriptive 

hJ G V S !? a * tract 1 " m ° f the level to its Ieft - There are many levels of abstraction 
besides the three shown here. 



Property 



Data Values 



Time Modelled? 



Types of Primitives 



Signal Level 



Signals 



Yes 



Relational 



Digital Level 



1, 0, float 



No 



Functional 



Table 1.1: The signal level versus the digital level. 



Digital and signal behavior differ in three ways (Table 1.1). First, digital values 
a e incomparable to signal value, Second, circuit primitives are relational (,'. " 
bidirectional) whereas digital devices are functional (,-..., unidirectional). Third 

fiSl !J m ant m drC ^' the rClatiVe ° rder in Which events occ ^ a*"^ the 
ittnttolfy. 6 CirCUlt ' ^^ deViC6S ^ time ' free ' ** -Pute their results 

si J^T^ r° CUS -! f thiS disser / tation is the automatic generation of a circuit's 
signal behavior from its structure (schematic). Signal behavior is the behavior of a 
circuit when viewed as a map from input signals to output signals. A signal is a time- 
varying voltage - intuitively, it what we observe on an oscilloscope when we probe 
1^' G T r K at l ng th ! Signal behavi ° r ° f lar * e circuits f ™ ^eir structure is 
I ^ ^7 ° f tWS reSearCk Th€ key is f0CUsin « the * enerat ™ method 
beha^or * '" ^ ^"^ ^ aCC ° Unt f ° r the circuit ' s di * itaI 

Verifying circuits is difficult for many reasons (Table 1.2). First, circuits are 
huge. Chips of up to half a million transistors are becoming common. Brute force or 
linear techniques simply fail. Seco nd, the signal behavior of a circuit must be derived 
time and switching devices. 



19 



• Circuits are huge, up to half a million transistors. 

• We must derive a circuit's behavior from its structure. 

• We must employ accurate circuit models. 

• A verifier must be fast. 

• Ad hoc systems are not enough to prove correctness. 

Table 1.2: Five reasons why verification is a hard problem. 



• Exploiting the hierarchy and structure of schematics. 

• Using intentional analysis. 

• Employing circuit models accurate enough to model the most common bugs. 

• Having a formal statement of circuit correctness. 

Table 1.3: Four techniques for attacking the complexity of verification. 



from the circuit s structure (schematic). Unfortunately, determining a circuit's full 
behavior is very hard and expensive. It is difficult to do either analytically or 
empirically. Third, accurate circuit models must be employed. Circuit models which 
are too simple will fail to catch bugs. On the other hand, circuit models which are 
too complex may make verification impossible. Fourth, an verifier must be efficient 
and fast to be usable. A designer needs quick response from his design system. 
Fifth, we want to prove our circuits are correct; merely finding and reporting bugs 
does not a verifier make. 

I have designed and implemented a system, called Silica Pithecus, for the multi- 
level verification of circuits. It accepts the schematic of a circuit and a specification 
of the circuit s intended digital behavior and determines whether the circuit meets 
it specification. Silica Pithecus uses four techniques to solve the above problems 
(Table 1.3): it exploits the hierarchy of a design, it uses intentional analysis, it 
employs circuit models accurate enough to catch the most common bugs, and it has 
a formal statement of circuit correctness. These are discussed below, in turn 

The hierarchy that is used to create a complex circuit is exploited during anal- 
ysis. Verification operates from the leaf nodes of a design to the root of the design 
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CHAPTER 1. INTRODUCTION 

All subcircuits of a circuit are verified before the circuit itself is verified. Two ben- 
efits accrue from this strategy. First, a circuit is verified only once - the first time 

Z l r S ,Z ~ « "T^ I*'' alWayS US6d f ° r the same P ur P° se ' * ^ed never be 
Z^a tT' Stc ™*>™**** <** be performed incrementally as a design is 
created. The amount of work in verifying the composition of two previously verified 
subcircuits is proportional to the amount of new information created by the compo- 
sition. The amount of work is largely unrelated to the complexity of the subcircuits 
themselves In terms of a usable, interactive system, finding errors quickly and 
incrementally is extremely important. Detecting bugs as they occur, rather than 
waiting until a design is complete, causes revaluation of designs at an early stage. 
It is not inconceivable that a design flaw in a small segment of a design invalidates 

wasteful ' CtIng the ^ ° nly aft6r the design is c °nipleted is 

This approach keeps the design process interactive and incremental. Silica Pithe- 
cus is mUracUvc because it can verify on demand any portion of the circuit, and 

11 m A Cr Tr T, lt Can analyze and verif y P arts of the c *cuit as they are 

entered. A designer is able to analyze and verify designs as they are created, rather 
than wait until the entire design (chip) is finished. 

Intentional analysis is proving only the important properties of a circuit hold. 

II ^dS £\£ ha : i ° r ° f a " rcuit nee f ~* b « known to verify that the circuit meets 
its digital specification. For example, it usually doesn't matter whether a signal's 

lollV IZ' c m V S , 4 - 5 ° r 4 - 6 V ° ltS - AU that is im P° rt ^t is that it is above 

~awJS *° r nU u arIy ' a " that "*** matter about a si * naI «"** be its value 
at steady state In this case it is unnecessary to calculate its intermediate values. 
By focusing on the relevant parts of a circuit's behavior and ignoring the irrelevant 
parts, predicting a circuit's behavior becomes a tenable proposition 

«fl S tn 1C \ P u h l CUS ' S C ° mp T nt m ° dels are aCCUrate enou 8 h to m °<^ (the sources 
of) threshold bugs, ratio bugs, charge sharing bugs, hazards, and races. These 

are the most common circuit bugs and the most complete set of bugs modelled by 

any one system cf .Table 1.6). Silica Pithecus's models do not include capadtive 

coupling or unclocked feedback, so bugs arising from those phenomenon are not 

„W £ fo ™ aI k statem ? en t of circuit correctness prevents Silica Pithecus from being 
ad hoc. The basis of the statement lies with the abstraction function used to map 
signals into digital values. The correctness statement guides much of the imple^ 
mentation dictates the relationship between the actual and intended behaviors of a 
ofTckcuh iZ6S the relationshi P between the structure, function, and context 

My theory of verification is designed for verifying synchronous MOS VLSI digital 

t^' T ^Z 6 n0t C ° nCerned With asynchronous circuits or process 

technologies other than MOS. Neither are we concerned with non-digital designs 



1.1. SCENARIO 

& L 

but it is harder to characterize what these are. For example, why is a bootstrap 
driver or a sense amplifier not a digital circuit? This dissertation defines as non- 
digital any circuit which relies on a race condition that can not be resolved using 
gate-delays. A bootstrap driver relies on a race between the driven node and the 
oad node, it is non-digital. Similarly, a sense amplifier relies on a race that is not 
the result of gate delays. 

Randy Bryant [Bryant86] imported the terms false negative and false positive 
into the vernacular of hardware verification. A false positive occurs when a verifier 
declares an incorrect circuit to be correct. Silica Pithecus is guaranteed never to 
give false positive. A false negative occurs when a verifier declares a correct circuit 
to be incorrect. Due to Silica Pithecus's conservative nature, it will give many 
« these. False negatives mainly arise when a circuit is more complex than Silica 
Pithecus s proof procedures and constraint processors can handle. Very often the 
form its false negative is "I can't prove this circuit is correct" rather than "This 
circuit is incorrect." 

This chapter has seven sections. The first section gives an overview of Silica 
Pithecus and gives an example scenario. The second section discusses hierarchical 
verincation. The third section gives some results of running Silica Pithecus on 
different circuits. The types of circuits which Silica Pithecus can verify are presented 
in the fourth section. Section five compares this research to other methods for 
verifying circuits. The sixth section highlights the contributions of this research 
The last section gives an annotated chapter listing of this dissertation. 

1.1 Scenario 

A schematic of Silica Pithecus appears in Figure 1.2. Silica Pithecus has three 
inputs and two outputs. 2 Two of the inputs, the schematic of the circuit to be 
verified and the circuit's intended digital behavior, were discussed above. The third 
input, logical constraints, are boolean expressions on the (digital abstractions of the) 
inputs of the circuit being verified. These boolean expressions are guaranteed to 
always be true. For example, logical constraints might dictate that the two clocks 
0! and fa are mutually exclusive. Other examples are dictating that a certain input 
is always asserted, or tha t either of two inputs will always be asserted. 4 

2 This is an idealized representation of Silica Pithecus's input/output behavior. Silica Pithecus runs 
in a interacts system where cu-cuits and programs coexist in the same database. Silica Pithecus 
has a couple of implicit inputs which are not represented in this diagram. 

^hVa1>Me C crd o aint8 Tk r erified t0 u 6 tn ? WhCn " CirCUit " USed M P" 4 of a krger circuit. 
Mlica Fithecus does not believe everything the designer says. 

7ot7ra^ fa Tl y ^, ! 1 ? iCal , COn8traint8 • ^^ ' tat€ l ° gical «"»*•**. «d temporal logical 
constraints. Steady state logical constraints make assertions about the boolean interpretation of 
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of circuit 
structure 



Logical 
Constraints 



Specification 
of digital 
behavior 



Silica Pithecus 



Constraints 



Either CORRECT or INCORRECT, Here's why 
Figure 1.2: Silica Pithecus as it appears to the user. 



One of the outputs of Silica Pithecus is a declaration of whether the circuit 
meets its digital specification, i.e., is correct. If the circuit is not correct, then the 
reason it is not correct is given to the designer. Example reasons include reporting 
ratio bugs, threshold bugs, or glitches. 

The other output is a set of constraints on the input signals. When satisfied, they 
guarantee that the circuit will exhibit its specified behavior. A given structure can 
exhibit many different behaviors; the constraints "project" out the desired subset of 
a structure s possible total behavior. 5 Structure alone does not determine function, 
structure and context together determine function. Examples of constraints include 
dictating that some input signal must not glitch or that some input signal must not 
sutler a threshold drop. 

Constraints are a very powerful idea. They allow very large circuits to be ver- 
ged- When a subcircuit's constraints are met, it means that the subcircuit will 
exhibit its specified digital behavior. Therefore, to generate the digital behavior 
of a circuit all of whose subcircuits have been verified, one need only prove all the 
subcircuit s constraints are me t, and then compose the subcircuit's digital behav- 

^Zlo^l^T ^Y 1 ™* ^^ 8teady State ' Tcmp ° ral l0 * kal con » tr ^ ™*e 
assertions about the boolean interpretations of the values of signals for all time. 

7n h Ll U ^ tiVe ana ! y M 'tTT^" * namC f ° r this ob "™*i°». t^y call it the Ncfunction- 

ZT«Z Z P H mC ? > ' Kleerl - Th " PriDCiple 8tateS that an oI * ct ' 8 beh ™ » *lwav, pre <ii- 
cated on the object's context. *««« 
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Latch 



8/2 




Figure 1.3: A Inverting Latch. 



iors. This method of generating digital behavior is very fast because the signal level 
behavior of the circuit need never be generated. We will return to this topic when 
we discuss hierarchical verification. 

Example 

Consider an Inverting Latch (Figure 1.3). This device stores one bit on its S node. 
The output of the Inverting Latch is the negation of the value on its S node 
The digital specification of the Latched Inverter is 

(df ((INVERTING-LATCH s) latch in) 
(stream-cons 

; this is the output 

(if latch (not in) (not s)) 

; this is the next state 

(INVERTING-LATCH (if latch ins)))). 

This program says that an Inverting Latch has one bit of state, s, and two 
inputs latch and in The inverter "returns" two values, the output and the next 
state of the device. The output and next state both depend on the state of latch. 6 

When Silica Pithecus is handed the schematic and digital specification of the 

tT. ?^ a ^' i \ ded ^ es that the circuit is correct and generates four constraints 
liable : 1.4). The first constraint requires that whenever Latch* is true, signal flow 
must be from In to S. If signal flow is not from In to S, say, because In is a 
precharged bus and S has more capacitance than In, then the circuit will not have 
its intended digital behavior. Th e second constraint requires that if Latch & falls 

6 This is not a complete description of the program. A complete description appears in Chapter 7. 
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1. Latchj =j> overpowers([In] /ri , [S] 5 ) 

2. falls(Latch t ) =» falls-first(Latch„In.) 

3. control(Latch.) 

4. no-drop(Latch.) 

Table 1 4: Constraints on the latched inverter cell. Latch, refers to the signal at 
node Latch. Latch, refers refers to the boolean interpretation of the signal at node 
Latch. The other notations are described in later chapters. 



during a computation 7 then it can only do so before In, changes state. That is, 

wtw \ G l 7^ !i able T ° n Com P utations when L^ch. falls, or, if In. is unstable 
when Latch, falls, then In. must change after Latch, falls. The third constraint 
requires hat once Latch, is asserted, it must remain asserted. The fourth constraint 
requires that Latch, not suffer a threshold drop. Latch, is prevented from suffering 
a threshold drop so that S. does not suffer two of them. If any of these constraints 
are violated, the circuit will not exhibit its intended digital behavior 

When a verified subcircuit is used as part of a larger circuit the subcircuit's 
constraints are checked. I anticipate that most errors in a design will be caught 
by the detection of violated constraints. Designers constantly work within semi- 
conscious digital abstractions of the analog properties of their designs. It is when 
they unknowingly break these semi-conscious digital abstractions that errors arise. 
The constraints that Silica Pithecus generates embody these semi-conscious digital 
abstractions therefore breaking the now concrete abstractions cause the constraints 
to be violated, and an error to be returned to the designer. 

1.2 Hierarchical Verification 

TZ h^ SP u ndS T* ,° f ItS Cnergy « eneratin 8 ™* abstracting a circuit's 
signal behavior. Hierarchical verification is a method -of avoiding much of this 
work. Consider a circuit composed of previously verified subcircuits (Figure 1.4) 
When the digital behavior of the whole can be derived from the digital behavior of 
the parts the signal behavior of the whole device need not be generated. 

This is precisely what hierarchical verification does. Hierarchical verification first 
processes the constraints of each subcircuit. If no constraint is violated, then the 

7 siTT U ^ n Sta ? T^ TT d ° Ck Change8 State ' A «"*•**» ends when the circuit reaches 
state. This idea is further elaborated in Chapter 3. 
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Figure 1.4: Hierarchical Verification. D is the whole design. Each part d< is assumed 
to be verified. The c.'s represent the constraints on each d,'s inputs. Assuming that 
none of the constraints are violated, the digital behavior of the whole design can be 
derived by composing the parts' digital behaviors. A constraint that can be neither 
proven nor disproven is propagated as a constraint of the top level circuit D. C 
stands for the propagated constraints. 



digital behavior of the whole is derived from the digital behavior of the subcircuits 
There are three possible outcomes of processing constraints: a constraint can 
be accepted, rejected, or propagated. A constraint is accepted when it is shown to 
hold. A constraint is rejected when is is proven not to hold. Rejected constraints 
are returned to the designer as errors. When there is not enough information to 
show that a constraint either holds or doesn't hold, the constraint is propagated 
up the structural hierarchy to be reprocessed when the circuit itself is used as a 
subcircuit. For example, because the input constraints Cl of component Dl in 
Figure 14 neither hold nor fail to hold, they are propagated as constraints on the 
inputs of D. Processing constraints is fast and efficient. There are five types of 
constraints. They are enumerated and discussed in Chapter 11. 

As a concrete example of hierarchical verification, consider a Shift Cell built out 
of two Latched Inverter Cells (Figure 1.5). The specification of this device employs 
the specification of the Inverting Latch. 

(df (SHIFT-CELL si s2) 

(let ((Left (INVERTING-LATCH si)) 

(Right (INVERTING-LATCH s2))) 
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Figure 1.5: Composing Two Latched Inverter Cells to Make a Shift Cell 



(lambda (in 11 12) 

(Right (Left in 11) 12)))) 

This digital specification says that a Shift-Cell takes two inputs and that its behavior 
is equivalent to two inverting latches, one feeding the other. 

There is one logical constraint for the shift cell: tmutex(Ll„ L2,). It declares 
that LI, and L2, are mutually exclusive. 

When given the above information, Silica Pithecus declares the Shift Cell to be 
correct and generates the following six constraints: 

• Ll 4 => overpowers([In] /n , [(S Left)] (5ie/0 ) 

• control(Ll,) 

• control(L2,) 

• no-drop(Ll,) 

• no-drop(L2,) 

• falls(Ll t ) =► falls-first(Ll„ In,) 

These constraints result from propagating the unresolved constraints of the two 
Inverting Latches to the Shift Cell. Of the eight constraints (four for each Inverting 
Latch), only two were satisfied: 

• L2» =» overpowers([C] c ,[(S Right)] (JJBfW) ) and 

• falls(L2 6 ) -> falls-first(L2„ C,). 
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Carry through 
71 xtors 

12.2 seconds 



Carry through 

71 xtors 

seconds 



Carry through 

71 xtors 

seconds 



Restored output 

71 xtors 

3.8 seconds 



284 xtors 9.4 seconds 



25.4 seconds total 
Figure 1.6: Verifying a 4 bit Manchester Adder. 



Note that as part of propagation, the names of nodes are changed from being local to 
the Inverting Latches to being local to the Shift Cell. For example, no-drop(Latch,) 
(for the left cell) becomes no-dro P (Ll.). When a node has no corresponding name 
tor it at the higher structural level a name based on the "pathname" of the node is 
generated for it. For example, the S node of Right is changed to (S Right) and the 
S node of Left is changed to (S Left). 

1.3 Results 

The time required to verify circuits is extremely encouraging. 8 Silica Pithecus has 
verified circuits of 9,000 transistors in 80 seconds. One particularly enlightening ex- 
periment is the one originally performed by Randy Bryant for MOSS YM fBryant85l 
and repeated using Silica Pithecus. 

In this experiment the ALU from [Mead/Conway] is programmed as an adder, 
which specializes it to be a precharged manchester adder [ref manchester adder], 
inis adder is a subtle device which uses many MOS features, and it is therefore an 
extremely good test case for an MOS verifier. 

Silica Pithecus verifies a 16 bit adder (over 1100 transistors) built from this 
cell m 51 seconds. The breakdown of times for this is very instructive. Consider 
the verification of a four bit adder, which takes 25.4 seconds (Figure 1 6) The 
first adder cell takes 12.2 seconds to verify. To verify a four bit adder takes an 
additional 13.2 seconds. Of this additional time, 3.8 seconds is spent verifying a 
slightly different version of the adder cell where the carry-out line is restored, and 
9.4 seconds processing the constraints of the four cells. By not reverifying the same 
part, and not generating signal be havior, hierarchical verification avoids extra work. 

'The timings here are preliminary. Silica Pithecus is not completely implemented. The timings 
are all within a factor of two, probably a lot less. By no means is Silica Pithecus tuned. A tuned 
version might run much faster. 
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1.4 Other Work 

Other work in ensuring circuits operate correctly is in four broad areas, bottom-up 
and top-down methodologies, simulation, electrical rules checking, and verification. 

1.4.1 Verification Versus Methodology 

Bottom-up and top-down methodologies are used to build circuits free of certain 
bugs. 

Bottom-up methodologies have two components: restrictions on the types of 
circuity that can be built, and restrictions how circuits can be composed to make 
larger circuits. These restrictions eliminate both certain classes of bugs and circuit 
classes of circuits. For example, threshold bugs are one type of bug that can be 
prevented by requiring that all signals coming from pass logic be restored The 
cost of preventing this particular bug, however, is very high. Requiring all signals 
to be restored excludes many types of circuits from being designed and costs extra 
silicon. 

Top-down methodologies start with a high-level, and therefore presumably cor- 
rect, specification of a circuit. The specification is incrementally refined into a 
concrete circuit. A fixed set of transformations are used during the refinement 
stage. Each transformation is guaranteed to preserve the correctness of the original 
specification and not to introduce any circuit bugs. 

Both top-down and bottom-up methodologies throw out the baby with the bath 
water: they make inefficient use of chip area and create slow designs. 9 Furthermore 
methodologies can't eliminate all classes of bugs - if they did, a designer would be 
overly restricted. For these reasons, we reject forcing designers to use a particular 
methodology. 

1.4.2 Simulation 

Today's designers debug their designs using simulation. Regardless of the level of 
simu ation, simulation has many problems (Table 1.5), the foremost of which is 
simulation cannot guarantee the absence of bugs. As designs become more and 
more complex, simulation becomes less and less reliable. Exhaustive simulation 
must be performed to prove circuits are correct. But exhaustive simulation for 
large circuits is either exponentially expensive (when a boolean or digital domain is 
used) or impossible (when an infinite domain such as signals is used). Verification 
which proves that a circuit works as intended for all inputs and state transitions, 
is completely reliable. Another p roblem is that simulation decontextualizes bugs. 

It^Zl l5 e r°/ etiCal TT f ° r thC T lting inefficienciM - Nonetheless, current technologies 
are wasteful of resources. Future research may alleviate this problem. 
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Simulation 



Is not complete 

Decontextualizes bugs 

Is non-compositional 

Weak circuit models 



Verification 



Is complete 
Pinpoints bugs 
Operates hierarchically- 
Accurate circuit models 



Table 1.5: The Failure of Simulation. Simulation has many problems which verifi- 
cation does not have. 



The output of a simulator is l's and O's. When a appears where a 1 was expected 

(or vice versa, or when an unexpected X appears), there is no clue about the 

source of the bug (».«., whether it comes from a logic bug, ratio bug, etc.). The 

designer must laboriously track down the source of the bug. This is true even 

when exhaustive simulation is performed. A verifier automatically pinpoints the 

parts of an implementation which do not match their specification; this precisely 

locates bugs. A third problem is that simulation is non-compositional. Even when 

al of a circuit's subcircuits are verified via simulation, the circuit itself must be 

fully simulated. Non-composibility is the key reason simulation cannot be used to 

verify large circuits. Finally, because simulators must constantly reevaluate the 

same subnetworks over and over again, simulators must used impoverished circuit 

models. Accurate circuit models would be too expensive to use for large scale 

simulation. Because verification only looks at each possible network once, it can 

use a more elaborate circuit model. 



Symbolic Simulation 

Recently symbolic simulation has been proposed for the verification of digital MOS 
circuits. Symbolic simulation uses variables and constants during simulation Bry- 
ant85]. When a circuit is symbolically simulated the result is an algebraic expres- 
sion. This algebraic expression is then verified to be the expression expected. Due 
to symbolic simulation's algebraic structure, it is capable of simultaneously simu- 
lating a circuit for many different inputs. This feature makes exhaustive simulation 
easier for some circuits. 

The major problems with symbolic simulation are lack of coverage, inability to 
catch races and hazards, decontextualization of bugs, and lack of composability. 
These problems arise because symbolic simulation is tied to a simulation paradigm 
thereby inheriting the problems of simulation. 

Lack of coverage means that symbolic simulation does not prove that for all 
inputs and states a circuit gives the correct output and goes to the correct next 
state. The problem is that a purely symbolic simulation would simulate transitions 
and states that never occur and would yield many spurious errors. To avoid this 
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problem, a designer must select simulation sequences that yield only states and 
transitions that can occur during real usage of the design. For example, if a device 
has two mutually exclusive inputs, then it is symbolically simulated twice: once with 
one input high and the other low, and once with the inputs reversed. Therefore, to 
get complete coverage, a designer must carefully craft a set of test sequences which 
fully exercises the chip. 

MOSSYM does not use MOSSIM's unit delay model. Instead, it uses Naher's 
[Naher] rank-order delay model. Therefore MOSSYM cannot verify the timing 
behavior of circuits. Bryant advocates the use of ternary simulation [Bryant83] 
as an extra pass to get around this problem. However, ternary simulation only 
finds races, therefore this methodology cannot verify circuits which rely on races. 

Like normal simulators, symbolic simulation decontextualizes bugs. The only 
difference is that symbolic simulation outputs boolean expression where normal 
simulation outputs ones and zeros. When discrepancies arise between the expected 
and actual results of simulation, the designer designer must still determine the cause 
of the discrepancy. 

Symbolic simulation is not composible. It is a monolithic tool and cannot take 
advantage of hierarchy. If two subcircuits are verified via symbolic simulation, this 
gives no handle what happens when the two subcircuits are composed. Symbolic 
simulation is at least quadratic in its running time, therefore it cannot be used for 
large circuits. 

Understanding why symbolic simulation is non-composable is very instructive. 
The basic problem is that the simulator assumes inputs are both driven and stable. 
For many circuits this assumption is invalid. The real inputs to a circuit may 
be precharged values rather than driven values, and they usually are not stable. 
Symbolically simulating a circuit does not indicate what the circuit does when 
connected to real signals. Therefore when a previously "verified" circuit is used as 
part of a larger circuit, the larger circuit must be simulated in its entirety. 

1.4.3 Electrical Rules Checkers 

Electrical rules checkers ensure that circuits are not malformed according to some 
structural criteria. Electrical rules checkers suffer from two major problems. First, 
they are completely ad hoc because they check that very specific configurations of 
circuits don't arise. Second, they often give many annoying spurious errors. 

The first commonly used electrical rules checker was Baker's [Baker]. This 
checker made sure that each node could be potentially pulled up and pulled down, 
that depletion mode transistors were used in known ways, that two or more thresh- 
old drops didn't occur, that Vdd and Gnd weren't shorted together, and that proper 
ratios existed in gates. Its major problem was finding a tremendous number of spuri- 
ous errors because it had absolutely no understanding of a circuit's logical structure 
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O L 

(e.g., which signals are mutually exclusive). It also had the problem of being non- 
hierarchical, it would find the same bugs over and over again. The output was so 

t U « n ^ 'l * t Pr ° gramS W6re Wfitten t0 filtCr ° Ut S ° me of the s P urious er ™ and 
to collect the repeated errors together. 

TV [Jouppi] was a timing analyzer that used some knowledge of a circuit's 
operation to avoid the problems of spurious errors. It applied a set of ad hoc rules 
over a circuit to determine the direction information flowed through transistors. An 
electnca rules checker built on top of TV which had no spurious errors when run 
on samp e circuits. One must use such a tool with caution, however. It suffers from 
two relaed problems. The first is that TV's methods for determining information 
are purely heunst lC and can fail without the designer knowing. Second, TV assumes 
hat ratios are correct to determine information flow, it then uses information flow 
to check ratios. This approach can fail in expected, and undetected, ways. 

Karplus [Karplus] also has an ad hoc approach to electrical rules checking He 
treats circuits as graphs and then uses graph algorithms to prove certain paths (sub- 

ruThi che n cks a C r C e Ur " ^ ^ ""* **** EXampkS ° f the g ~ ph f " n 

1. Avoid shorting power. 

2. Avoid changing the inputs. 

3. Avoid parallel pullups. 

4. Avoid gates in the middle of pulldown chains. 

5. Avoid charge-sharing. 

6. Avoid odd inverter cycles. 

Some of these rules are not well-motivated and potentially unneeded. For exam- 
ple Rule 2, avoiding changing the inputs, is not needed when the input is connected 
to the output of a gate. The reason for avoiding parallel pullups is to make ratio 
checks less prone to error The reason for Rule 4, avoiding gates in the middle 
of pulldown chains, is so that ad hoc programs which try to determine signal flow 
won t get confused. Having ad hoc rules so that ad hoc programs will work better 
seems like poor methodology. Also, enumerating the ways a circuit can be mal- 

b°eTntmer n a°ted a ^^ " '" ™* ^ "** W *" ^ drCUit formations ca * 

1.4.4 Other Types of Verification and Other Verifiers 

Very little work similar to the work discussed in this dissertation has been done. 
People have worked on multilevel verification, and have worked on generating be- 
havior from structure, but always with a different focus than that presented here 
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The technologies and models used by previous researchers differ from mine. 
Specifically, earlier work on deriving behavior from structure were either for TTL 
I Wagner], or used inadequate circuit models for MOS [Gordon, Barrow82l. The 
types of circuits built from TTL and from MOS are completely different, and the 
models of [Gordon82] and [Barrow] can't catch charge-sharing bugs, ratio bugs, 
threshold bugs races, or hazards. Also, Wagner's verifier was not automated and 
could only handle small circuits. Barrow's verifier is discussed in detail below 

Gordon has since improved his model to make transistors be bidirectional and to 
include time [Gordon84b]. He uses higher order logics for describing and verifying 
circuits [Gordon84]. Using logic is an improvement over more functional approaches 
Logic easily captures the bidirectionality of transistors and logic is well known' 

fbTtTh^.H ' ", ^ n ° bett f than eafIier f0rmaHsmS f ° r describin *> or zoning 
about, the electrical aspects of circuits. 

Research on multilevel verification has also been done [Eveking] [Gordon84cl 
Previous work made explicit the notion of an abstraction function for mapping 
between levels. Some even had partial abstraction functions. However, none have 
onl 7 Underst - d ] he / ole «f constraints. One researcher [Eveking] noticed that 
onstramts (he called them assertions) were needed to ensure inputs were valid 
(..e. , mapped into the higher level descriptive domain). He, however, did not make 
the observation that constraints were also needed to ensure outputs were valid 

Jutem^T ^ ° ne thC COntributions of th " dissertation and is the basis for 
automatically generating constraints. 

o„ti?n the f a !l emPtS I 1 .™*®** M0S circuits ™» now be discusses, followed by an 
outline of other work in verifying diverse properties of digital systems. 

Verify 

v! r 1t eS f R SHiCa f lt v C v' 22 ° nIy ° ther im P Ieme *ted verifier for MOS circuits is 

Sfie [ i 6 T° 1st t ?; iffera *r. Silica Pithecus in two very im P° rtant ~W 

(lable 1.6). First, it has no explicit notion of abstraction or multiple levels of 
description it is a monoverifier. Second, its circuit model is extremely weak. It 
cannot model charge-sharing bugs, ratio bugs, threshold bugs, races, or hazards. 

„, J ef i S /° CUSeS ° n VCrifying digital de3ignS - U models circuit components and 

^tt sSTpT*" " ?"?*" digital devkes - (That is ' Verify «™- the 

result that Silica Pthecus is trying to prove, namely, that circuits can be described 
as time-free digital devices.) Given two different digital descriptions of the same 
design it can determine whether the two descriptions are the same. One of the 
descriptions is derived directly from the structure of the design, the other is the 

he'lt r w eCaU !! ^ drCUit ' S behaVi ° r and its s P«incation are described at 
the same level (,.«., the digital level) an abstraction function is unneeded. 

(Silica Pithecus could use the capabilities of Verify. When Silica Pithecus verifies 
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Table 16: Verifiers and Simulators for MOS Circuits. This table shows the different 
characteristics of MOS verifiers and simulators. The top row highlights Verify. This 
venfier s strength is in verifying digital systems rather than verifying circuits. The 
second row highlights two popular simulators. These simulators have reasonable 
circuit models but don't perform verification. The last row shows Silica Pithecus 
which has the best of both worlds. It can formally prove a circuit is correct, and 
its models are better than the simulators' models. 



large circuits, their structural and functional specifications must match. This makes 
comparing the abstracted and specified behaviors simple: Silica Pithecus shows 
that the subcircuits correspond to subfunction in the digital specification and that 
the wires m the circuit correspond to dataflow in the digital specification. The 
comparison of arbitrary digital expressions occurs only for leaf cells. Silica Pithecus 
and Verify are complementary programs, the former verifies circuits and the latter 
verities digital designs.) 



Functional Verifiers 

Functional verifiers are multilevel verifiers where the concrete domain is the digital 
level and he abstract domain is at some higher level such as the arithmetic level. 
Functional verifiers are complex because the abstract domain are very rich. Proving 
that two expressions denote the same value can require difficult theorem proving 
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An interesting functional verifier was created by [Hunt]. He began with the 
Boyer/Moore theorem prover [Boyer]. Wherever the theorem prover was inade! 

boo In 7T- Tl^ b f MO ° re ' The PrimitiV6S ° f Hunt ' s circ ^ -re idealized 
boolean (strictly Estate) gates. He designed a microprocessor and verified that it 

rTroo^ J PeC K? tl r- "T* he empI<>yed the ^/Moore theorem prover his 

d scrL "f L 6 ^ mdUCti0n ' Theref ° re he COuld P rove that Parameterized 
descnptions of his circuits were correct, something no other verification system has 

done. For example, he was able to prove that his specification for an n-bit adder 

Ver^vT atwf ,° f itS / artiCUlar ^ ° ther VerifierS («•'" SiIica Pithecus a *d 
^t^ ? r T ed d6SCnp 1 tions ' but the Ascriptions must be concretely 
instantiated before verification can be performed. 

Protocol Verifiers 

TonTol 01 V6rifierS ! h ° W ^ at S ° me communi cation and arbitration scheme properly 
controls some system. For example, protocol verifiers prove that a system win 
a ways service or acknowledge a given request. Protocol verifiers are also used to 

cTaL a / i y n n tK r0n0US 7 Ste T Pr ° tOC01 VerifierS a " untt that P rimitive * ^Pond to 
of thf^ th61 V npUtS ? * S ° me finitC dday - The trick is to P^ve that regardless 
of the delays which can't be accurately predicted, the system will still work 

svstplT 1 ? glCS ^ ° ften USCd t0 Spedfy the desired Properties of asynchronous 
systems and communication protocols [Mishra/Clarkej [Moszkowski] [Fujital. They 
formalize notions such as "before," "after," and "following » 

wTTh ^ T* C ° nfusion in the immunity between verifying asynchronous sys- 

i"it is a V n 6 [nr g T """l *"**- ^ PTOUem ta that an ^-hronous 
c Z\i lnstan « of a * asynchronous system. Therefore researchers sometimes 
claim they are verifying circuits when their methods have little to do with circuits 
(other than circuits are used to implement asynchronous systems). Their claim 
is partially true, however, the claim is beside the point. One could implement an 
asynchronous system using people, instead of circuits, and their methods would still 

Verification of Sequential Systems 

This category of verifiers proves that a system exhibits the correct behavior over 
many cycles. Examples include verifying that a bit serial adder really adds two 
numbers, or verifying that microcode correctly implements its intended macrobe- 

vJl^t^^h^K^ 'T' " ^ ad h ° C fashi ° n ° n this tQ P ic - B <*h 
Verify and MOSSYM have been used to verify a the correct behavior of a design 

r c ™ T«7 n fify ^ 6Xtended t0 Verify ' With human intervention, the 
microcode of a small computer. MOSSYM has verified bit serial adders 
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Figure 1.7: Silica Pithecus's place in the verifier community. 



verification 7 ^^ ^ '**' *" ^ d ° ne ° n tWs ta in the field of ™ c ™°*e 
Silica Pithecus's place in the verifier community is shown in Figure 1.7. 



1.5 Contributions of this Research 

The main contribution of this research is a formal abstraction mechanism for veri- 
fying the signals of a circuit correctly implement the digital abstractions envisioned 
by the designer. This includes, for example, proving signals can be viewed as ones 
and zeros, that nodes are capable of storing bits, and that control signals don't 
glitch A major difficulty is deciding which signals are intended by the designer to 
be state bits, control signals, or data signals. These concepts are related to the role 
ot a signal and are unrelated to electrical considerations. 

The second contribution is an efficient method for the automatic generation 
of a circuit s signal behavior from its structure (schematic). This is one of the 
contributions of this dissertation. The key is focusing the generation method on 
only those parts of a circuit's full behavior that account for the circuit's digital 
behavior. No previous system with reasonable circuit models has predicted the 
behavior of large MOS circuits solely from their structure. 

Other contributions and ideas are listed below. 
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A formal model of multilevel verification. 

I precisely define what it means to prove a circuit is correct. Other researchers 
in multilevel verification have had a similar statement of correctness, but they all 
missed the role of context in their definitions of correctness. 

A method for formally deriving constraints. 

Besides specializing behavior, the purpose of constraints is ensure that the behav- 
ior of a given design is abstractable to the next higher level of description. This 
observation yields a method for automatically generating many of the constraints 
on a design. 

A formal statement of the relationship between structure, function, and 
context. 

Hierarchical verification depends on the explicit dependence between structure, 
tunction, and context. 

A method for symbolically predicting the behavior of a circuit solely 
from its initial state and inputs for any valid state and inputs. 

As mentioned several times in this chapter, Silica Pithecus must both derive a 
circuit s signal behavior from the circuit's schematic and also abstract the signal 
behavior to the digital domain. A major contribution of this thesis a method for 
efficiently deriving a circuit's signal behavior from its schematic. 

Intentional analysis. 

Intentional analysis automatically falls out of the statement of circuit correctness 
It allows a venfier to concentrate solely on the behavior of a design that contributes 
to the design s behavwr at the higher levels of abstraction. 

A Constraint System. 

The constraint system serves a dual role. The constraints themselves serve as part 
of the proof that a given circuit will exhibit its intended digital behavior. Their 
other role is the mechanism by which very large circuits are verified. 

Accurate models. 

Verification would be meaningless if there were large classes of bugs which could not 
circuit bugs rCSearCh US6S COmp ° nent models ca P ab,e of modeling common 
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An existence proof that the theory works. 

Silica Pithecus is proof that a verifier with an accurate circuit model can be made 
to run, and run quickly, for large circuits. 

1.6 Organization of the Thesis 

This dissertation has four major chunks: the circuit model (Chapter 2), the theory 

of multilevel verification (Chapters 3 through 5), the structure of Silica Pithecus 
Chapters 6 through 9), and the theory and practice of hierarchical verification 

(Chapters 10 and 11). An annotated chapter listing appears below. 

Chapter 1, Introduction 

This chapter delineates issues, presents an example, introduces terminology 

summarizes results, and presents an annotated chapter listing. 

Chapter 2, Component, Signal, and Network Models 

Chapter 2 presents Silica Pithecus's component, signal, and network model. 

ine signal model describes the primitive elements manipulated by circuits The 
component model describes the primitive devices for manipulating signals The 
network model describes what the meaning of interconnected components is. An 
analogy can be made between circuits and programming languages, where signals 
correspond to primitive data types, components correspond to primitive operations, 
and programs. 

Chapter 3, Multilevel Verification 

There are many different levels of description {e.g., signal, digital, functional) of 
a circuit s behavior. Multilevel verification is defined as proving that two different 
levels of description describe the same behavior. The lower level of behavioral 
description of a circuit's behavior is the circuit's concrete behavior, the higher 
level description is its abstract behavior. Chapter 3 presents the formal basis of 
multilevel verification. It presents examples of both of verifying a circuit's signal 
behavior against its digital behavior, and of verifying a circuit's digital behavior 
against its functional behavior. 
Chapter 4, Time and State 

Chapter 4 discusses how state and time are incorporated into the formal model 
of the previous chapter. The major result of Chapter 4 is method for symbolically 
predicting the final state of a circuit solely from its initial state and inputs. The 
prediction does not perform a simulation of any kind. 
Chapter 5, Non-electrically Isolated Inputs 

Chapter 5 extends the theory of Chapters 3 and 4 to include circuits with non- 
electncally isolated inputs. 
Chapter 6, Silica Pithecus 
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Sili^Vrr" 1 ^ ° f S i IiCa Pi f eCUS iS Pr6Sented in Cha P ter 6 - The naajor parts of 

wWrh rf ?!* ^ I 1185 ^ thC n6Xt f ° Ur Chapters - Parts of Silica P^hecus 
which do not deserve their own chapters appear in Chapter 6. This includes the 
representation of circuits and Silica Pithecus's comparison methods. 
Chapter 7, The Specification of Digital Systems 

A I,?' 1S T ** Specifj i n « both di * ital b ^avior and digital systems is discussed. 
A language for the specification of digital systems is presented. This language has 
an interpreter so specifications can be debugged by executing them. 
Chapter 8, Generating Net Behavior 

diff^nt^w" " f UCtU / a [ re P^tation of a circuit that emphasizes the 

f f lorithl or " r ^ u 6 ^ memW ° f dUring Settling ' Cha P ter 8 *»-» * 
an algorithm for generating net behavior. 

Chapter 9, From Net Behavior to Digital Behavior 

behfvio^tV^f Tn * Si f nal . behaVi ° r fr ° m net behavior and then abstra <* «*»! 
Chanter Q H § , ^ " " W ° n effident '° generate di * ital be havior directly. 

Chapter 9 discusses how the network model is invoked to interpret nets and how 
the interpretation is abstracted to the digital domain 
Chapter 10, Hierarchical Verification 

verifi^T and T aCtiCe ^° f hierarchicaI verification and hierarchical multilevel 
verification is presented in Chapter 10. 

Chapter 11, Processing Constraints. 

how S th C e a v P , itheCUS ™*a ^ tyP6S ° f COnstraints - Ea <* of these constraints and 

-ofTon 7 , Pr °, CeSSed , 1S presented in Cha Pter 11. The preliminary processing 

of constraints is identical, but each type of constraint has it own special theorem 

provcrs. 

Chapter 12, Future Research 

Chapter 12 discusses problems I never got around to solving. This includes 
using the information needed for verification to create an accurate timing e ima 

SS^Zg* f6edbaCk ' deali - Wlth CaPaC ^ «** -« S. 



Chapter 2 

Component and Signal Models 



We now turn our attention to the signal, component, and network models used by 
bihca Pithecus. This modularization corresponds to describing the semantics of a 
programming language in terms of its primitive data types, primitive operations on 
these types, and what the meaning of a combination of primitive operations (called 
a program) is. v 

The component model used by Silica Pithecus is as accurate as the component 
model used by any large scale simulator. 1 Silica Pithecus's component model is 
superior to MOSSIM's model, and, not counting modeling how long a circuit takes 
to settle, is superior to RSIM's model. To a first approximation, if MOSSIM or 
KbIM can simulate a circuit, then Silica Pithecus can verify it. 2 

Silica Pithecus could employ a simpler model than it does, such as MOSSIM's 
switch level model This would save some analysis time. However, the time savings 
would not be worth the less accurate verification that would result. For example, 

MOSsfMWdr 1 ' ^ ^ aWe ^ ^^ thre8h0W " rati ° bU8S if * ■*** 

This chapter has five sections. The first section describes Silica Pithecus's com- 
ponent model. A new way of describing circuit a circuit's dynamic structure, called 
net behavtor, is presented in the second section. The third section describes Silica 
Pi hecuss network model, that is, what interconnected components mean. Silica 
Pithecus s signal model is described in the fourth section. A discussion of the bugs 
which can and cannot be modelled are presented in the fifth section. 

1 A large scale simulator is a simulator that handles circuits in excess of 10,000 transistors. 
2 This statement is only partially true, as Silica Pithecus won't verify circuits that use unclocked 
U k ! trt ^ ^ bC aWe t0 PTOVe 8 ° me COTTeCt CirCuit8 « «™ ct ' but '<>' most d«tn» 
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2.1 The Component Model 

Silica Pithecus uses a component and network model similar to RSIM's model [Ter- 
man] except for RSIM's features which are concerned solely with timing. For exam- 
ple, there is only one effective resistance for any given transistor, rather than three. 
We will first describe transistors, then nodes. 

Transistors 

Conducting transistors are modelled as resistors in series with a threshold drop 
devtce The resistance of a transistor 3 depends on the gate voltage of the transistor 
and the channel length and width of the transistor. A threshold drop device appears 
in circuit diagrams as a square with an X in it. 
The resistance depends on three factors: 

1. Length and Width: The resistance of a transistor is proportional to its 
channel length divided by its channel width. 

2. Type: The type of a transistor determines the resistance of a unit square of 
the active region. 

3 " !t ate i. Y? 1 ?* 881 The resistance is doubl «* if the gate voltage has suffered a 
threshold drop. 

Silica Pithecus's model for an enhancement mode transistor divides a transistor 
into four operating regions (Figure 2.1). The X'd square represents a threshold 
drop device. This device acts as a regulator preventing more than a certain amount 
of charge (electrons) from being pushed through it. For example, in the third case 
of the figure only enough charge can be pushed through it to raise the voltage 
on the node to its right to 3.5 volts. When the gate voltage is between 1.5 volts 
and 3.5 volts the resistance of the transistor is unknown (denoted X). A depletion 
drop'devlce " * ***** ° f resistance L / W with no concomitant threshold 

• T , h i S iS % sim P u le , transistor modeL There are **ny real phenomena it ignores or 
simplifies. Nonetheless, the model is accurate enough for our needs. 

There is nothing sacred about our choice of voltages. We have chosen the upper 
rail as 5 volts and the lower rail as volts for convenience. These voltages could have 
been left symbolic (we will sometimes write them as Vdd and Gnd, respectively) 
however, this wouldn't have chan ge the results or theories of this dissertation. 

3 More accurately: "the resistance of the resistor the transistor is modelled as.' 
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nMOS Transistor S __n__ D 
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voltage(G)<1.5 ==> - — 

1.5 <= voltage(G) < 3.5 = => 



2L/W 
3.5 < = voltage(G) < 5 = = > >v A/v !£ 



5 = voltage(G) = = > 




Figure 2.1: Silica Pithecus's Transistor Model. Enhancement transistors are mod- 
elled as resistors in series with a voltage controlled switch. The resistance of the 
transistor depends on the gate voltage. When the gate voltage is low enough 
then the transistor is modelled as an open switch. When the gate voltage is "fall 
strength the resistance of a transistor is L/W where L is the channel length and W 

M I ,?! £ ThC resistance is do <*led when the gate voltage has suffered 
a threshold drop. The X'd square represents a threshold drop device. This device 
acts as a regulator preventing more than a certain amount of charge (electrons) 
from being pushed through it. For example, in the third case above only enough 
charge can be pushed through it to raise the voltage on the node to its right to 3 5 
volts. When the gate voltage is between 1.5 volts and 3.5 volts the resistance of the 
transistor is unknown (denoted X). Depletion transistors are modelled as resistors 
ol resistance L/W with no concomitant threshold drop device. 
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Figure 2.2: A Latched Inverter Cell. This cell differs from an Inverting Latch by 
the placement of the latch gate. 



Nodes 

Silica Pithecus models nodes as capacitors to Ground. Capacitance is measured in 
dimensionless units. (When timing is a concern, capacitance needs proper units.) 
Nodes whose capacitance is not declared have a capacitance of 1. 

2.2 Net Behavior 

-During settling a node is a member of many different nets. The different nets are 
called the node s possible nets. Depending on the pattern of conducting transistors 
and the topology of the circuit, the sizes of a node's possible nets can range from 
containing a single node (the node itself), to containing every node in the circuit. 
A node s possible nets and the conditions under which they are active is called the 
nodes net behavior. Net behavior is a function that maps time into nets. Given 
some time t the net behavior of node N returns the net that N is a member of at 
t . A circuit s net behavior is the sum of its node's net behaviors. 

For example, consider a Latched Inverter Cell (Figure 2.2).< The S node of this 
device has three possible nets, which are shown in Figure 2.3. The net on the left, 
the single node S, arises when Latch* is not asserted. The middle net occurs when 
Latch* ,s asserted and In* is not asserted. The net on the left arises when both 
Latch* and In* are asserted. 

We will use a textual notation for nets: if a net contains nodes A, B, and C 
then it is textually written [A, B, C]. For example, the abbreviations of the nets of 
Figure 2.3 are [S], [S, Vdd, Out], and [S, Vdd, Out, Gnd], respectively. 

* A Latched Inverter Cell differs from an Inverting Latch (Figure 1.3) by the placement of the latch 
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Figure 2.3: Possible Nets of the S Node of the Latched Inverter Cell. 



Current doesn t flow between nets. This has two intertwined benefits. First, 
net behavior is a wedge by which we can modularize a circuit's behavior to make 
analyse possible Second, all the possible sources of change to a node's voltage 
are contained in the node's possible nets. Therefore a node's voltage over time can 
be predicted by analyzing the node's net behavior. (This analysis is presented in 



2.2.1 Representing Net Behavior 



A node N s net behavior is represented by a net behavior expression written as 
McCar hy conditional [Lisp 1.5]. The conditional consists of a series of clauses. 
Each clause consists of one predicate and one net. The predicate is a boolean 
expression If a predicate is true then N is a member of the predicate's associated 
net. N^t denotes N's net behavior. 

For example consider again the S node of the Latched Inverter Cell (Figure 2.2) 
The representation of its net behavior is 



3n.t 



A t . Latch»(t) A In t (t) -► [S Vdd Out Gnd], 
Latchj(t) A N0T(In 4 (t)) - [S Vdd Out], 
NOT(Latch d (t)) - [S] 



This formula is called a net behavior equation. The left hand side of a net behavior 
equation is the name of a node subscripted by net and the right hand side is a net 
behavior expression. 

The net behavior of a circuit is a listing of the behavior equations of its nodes. 
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source,*, = A t . gate 6 (t)-> [source drain], 

N0T(gate 6 (t)) -► [source] 
drain^j = A t . gate 4 (t)-> [source drain], 

N0T(gate t (t)) - [drain] 
gate^t = A t . [gate] 

Table 2.1: Net Behavior Equations of the nMOS Transistor 



For example, the net behavior of an n-channel transistor has three equations, one 
for each node (Table 2.1). 

Efficiently finding the possible nets in a circuit requires understanding the logical 
structure of a design, i.e., which signals are mutually exclusive and how some signals 
depend on other signals. Without this knowledge a circuit can appear to have an 
exponential number of nets with respect the number of transistors in the circuit, 
rather than the linear or quadratic number of nets intended by the designer. For 
example, a barrel shifter's control signals are mutually exclusive. Therefore, it has 
only a linear number of nets. But unless this knowledge is used, the barrel shifter 
will appear to have an exponential number of nets. Chapter 8 discusses the methods 
of employing the logical structure of a design during circuit analysis. 

We now introduce a some terminology that is used throughout this dissertation. 
Off-chip inputs (e.g., Vdd, Gnd, clocks) are assumed to be driven and are called 
driven nodes. Nets containing at least one driven node are called driven nets. All 
other nodes and nets are called undriven. What others have called a storage node 
we treat as a degenerate case of an undriven net containing only one node. A net 
contracts when some transistor in it shuts off thereby partitioning the net into two 
smaller nets. A net expands when one of its boundary transistor turns on thereby 
connecting it with some other net. 

2.3 The Signal Model 

Silica Pithecus models signals as functions which map time into a voltage and a 
strength. That is, * 

Signal : time -*■ voltage x strength. 

Intuitively, a signal is what we see on our oscilloscope when we probe one of the 
nodes of the circuit and watch the circuit in operation. Signals have two compo- 
nents, voltage and strength. The voltage of a signal is well understood and will not 
be explained. Signal strength is explained below. 
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Figure 2.4: Signal Strength 



2.3.1 Signal Strength 

Signals emanate from nets of nodes (hereafter just called nets). The strength of 
a signal at some point in time is the the sum of the capacitances of the nodes in 
the net from which the signal emanates at that point in time. Driven nodes are 
considered to have infinite capacitance. 

For example, consider the simple circuit of Figure 2.4. Assume that there is 
probe at node Y. We are going to measure the strength of Y„ the signal at Y for 
different states of the circuit. When all the transistors are off, the strength of Y. is 
n. If B is then asserted, the strength of Y, goes ton + m. Asserting A at this point 
causes Y, s strength to be oo because the "capacitance" of VDD is oo. A signal 
whose strength is oo is a called a driven signal. 

The strength waveform of a signal 5 at a node encodes the charge sharing pat- 
tern of the node. An increase in X.'s strength indicates X is increasing the number 
of nodes with which it shares charge. A decrease in strength indicates that X is 
decreasing the number of nodes with which it is sharing charge. Knowing that a 
signals strength only decreases or only increases during a computation is very valu- 
able. For example, when a signal's strength only decreases during a computation 
then the nodes in the signal's final net retain their initial charge. Chapter 4, which 
shows how a circuit's fina l state is predicted, discusses the strength of signals in 

5 A strength waveform is analogous to a voltage waveform. It is a plot of strength versus time. 
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voltage 



strength 




Figure 2 5: Notation for Time. We assume that a circuit is at steady state when its 
inputs change By convention, U is the time at which the first input changes and t, 
is the time when the circuit settles again. 



detail. 



2.3.2 Notation for Talking about Time 

We assume that a circuit starts out at steady state, that its inputs change, and 
that the circuit then settles to a new steady state. We call the change of an input 

LTsf Tr; e * U "t an \ that a drCUlt iS CaUSed to com P ute b * a computation 
request The time when the inputs first change is called the initial time and is 

denoted t,-. The final time, denoted, *,, occurs when the circuit achieves steady 
state. These times are illustrated graphically in Figure 2.5. 

As a consequent of this notation X,(f.) denotes the value of X. before a compu- 
tation request is issued. X,(*,) denotes the value of X, when the circuit settles A 
signals stable during a computation request R {i.e., from the time R starts to the 
time the circuit settles) if and only if the signal provably never changes during this 
uim.6. 

N^,) is called N's initial net. N wt ( t/ ) is called the N's final or chosen net. 
Following standard nomenclature, the predicates which select a node's initial and 
final nets are called the node's precondition and postcondition, respectively 
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Figure 2.6: Creating Equivalent Voltage Dividers. 



2.4 The Network Model 

Given a net of transistors and a node of interest, the network model says how the net 
is interpreted to yield a voltage and a strength at the node. Thevenin equivalents 
are used to interpret net containing driven (,'.•., off-chip) nodes. A charge sharing 
model is used for nets not containing driven nodes. 

The final voltage of a node N in a net containing driven nodes is determined 
by creating the Thevenin equivalent of the net regarding JV as the net's output. 
The calculation is similar to the calculation presented by [Terman], except that 
intervals are not used in the calculation. The subnet "above" the node [i.e the 
subnet eading to Vdd) and the subnet "below" the node (i.e., the subnet leading 
to Gnd) which form the voltage divider for the node are each reduced to yield 
characteristic voltages. It may be the case that there is no subnet "below" the 
node, in which case the node is pulled-up. 

An example of creating an equivalent voltage divider appears in Figure 2.6. In 
this example a net with two transistors above the output node and two transistors 
below the output node are replaced by one equivalent transistor above the output 
node and one equivalent transistor below the output node. 

Final voltages cannot be determined for nets not containing driven nodes because 

he verifier can t know the charge on the nodes in the net. Instead, Silica Pithecus 

locates a dominant node whose capacitance is sufficiently greater (more than 10 

times) than the sum of the capacitances of all the other nodes in the net. If such a 
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node exists, then all the nodes in the net will assume the voltage of the dominant 
node. 

erro/ S, ?nf a ^ tV ""I ^ ^ Silka PitheCUS wiU si * nal a charge-sharing 
error (Of course, Silica Pithecus is careful only to generate such errors for nets 
which must yield a valid voltage.) 

2.5 Bugs Modelled and Not Modelled 

We first discuss bugs that can be caught, then bugs that can't be caught. 

2.5.1 Bugs Modelled 

The bugs that can be modelled are listed below. 

Charge Sharing A charge charging bug occurs when two or more nets share 
charge but neither has sufficient charge to "overpower" the other thereby re- 
sulting m invalid voltage levels. Circuit techniques such as precharged buses 
can be verified only by a system that properly models nodes. A verification 
system which modelled all nodes as having the same capacitance could not 
verify a circuit which used precharged nodes. 

Ratio Bugs A gate in an nMOS circuit is a voltage divider. A gate is capable 
of driving its output to the upper rail, but incapable driving its output to 
the ground level. (Because that would imply that the pulldown has zero 
resistance.) The resistances of the two "halves" of the voltage divider must 
be carefully balanced to ensure that the output is close enough to ground 
to ensure a reliable zero level, but not so close that that the current flow 
through the gate is excessive. Ratio bugs can be modelled because transistors 
are modelled as resistors whose resistance is dependent upon the geometric 
characteristics of the transistors. 

Threshold Bugs Transistors are not ideal switches. Transistors can only pass a 
certain voltage that is some fixed amount below the voltage on their gates 
As signals pass through pass transistors they suffer threshold drops which is 
exhibited as a truncation of a signal's voltage. There are two different types of 
bugs caused by threshold drops. The first is ratio problems with gates because 
the resistance of a transistor depends upon its gate voltage (Figure 2.7). The 
second is threshold drops adding up when a signal suffering a threshold drop 
gates a transistor T causing the signal gated by T to suffer two threshold 
drops. Signals which suffer two threshold drops have lost enough voltage to 
become invalid signals. Threshold drops are modelled by including an explicit 
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Figure 2.7: Two Differently Sized Inverters. The minimum-sized inverter does not 
work tor all inputs that the nonminimum inverter works for. It will only work if 
its input has not suffered a threshold drop. The nonminimum inverter works for a 
greater range of inputs at the cost of using more area and being slower than the 
minimum sized inverter. 



threshold drop device in the transistor models. Other systems, e.g., RSIM 
have not modelled threshold drops. ' 

Races A race occurs between two signals when the final state of circuit is a function 
of which signal changes first. Often the proper operation of a circuit requires 
that when a race happens, one of the two signals always changes first. Races 
can be modelled because the signal model explicitly includes time. Some 
systems, such as MOSSYM, do not model time, and therefore can't detect 
races. 

Hazards Hazards can be considered as degenerate cases of races where a signal is 
racing with itself. A hazard occurs when a circuit can detect the number of 
transitions a signal has during settling. For example, if a signal begins and 
ends at zero, but the circuit it's in has a different final state depending on 
whether the signal has zero or two transitions, then a hazard occurs when the 
signal goes through two transitions. 

2.5.2 Bugs Not Modelled 

Bugs which can't be modelled by Silica Pithecus are those arising from unanticipated 
capacitive coupling and spikes on off-chip inputs. 

Ignoring Capacitive Coupling 

Capacitive coupling is ignored so that number and size of a node's possible nets 
is minimized. If capacitive coupling were modeled, then nets would span the chip 
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Figure 2.8: MOS transistor symbol with explicit C gt and C gd . 



and the circuit would have to be analyzed monolithically.* This analysis would be 
infeasible for even moderately sized circuits. In this section I show the sources of 
capacitive coupling, discuss the drawbacks in ignoring it. 

«f J£J ! W ° ^ sour ^ of ca P acitive coding are the gate to source capacitance 
of MOS transistors, and the coupling of physically close wires. The dominant source 
is the capacitance of transistors, by far. 

A MOS n-channel transistor is modelled in detail as having a capacitor between 
its gate and source (Figure 2.8) and between its gate and drain. This capacitance 
can be increased by the inclusion of an explicit capacitor. This capacitor forms a 
coupling between the gate and source nodes of the transistor through which current 
can now. 

There are two undesirable effects of ignoring coupling capacitance: not being 
able to model anticipated capacitive coupling, and not being able to catch bugs 
arising from unanticipated capacitive coupling. The first undesirable effect, not 
being able to model circuits which depend on capacitive coupling can be overcome 
by making such circuits primitives of the design system. They can then be treated 
specially, as other primitives (e.g., transistors) are. For example, bootstrap drivers 
could be treated this way. No other large scale analysis system (e.g., TV [TV 
Jouppi], MOSSIM [BryantSl], RSIM [Terman], Crystal fOustexhoutJ) has handled 
capacitive coupling in a general way. For example, [TermanJ does a prescan of 
the circuit which recognizes boo tstrap drivers and replaces them with primitive 

e There is no way within my framework for heuristically examining only those parts of the circuit 
where capaaUve couplmg effect, are significant. There are two reLn, for this First, I am trying 

LcltiinTi 30 ? ' Can _, make Ckar StatemenU about what * ™™ '° verify a circuit T "! 
otdkate 7 "f' UlterferM T th L th » *oal. Second, there is no clean mechaniL for a designer 
to mdicate parts of the circmt which bear closer inspection by the verifier. 
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elements. Other than ad hoc checks, there does not seem to anything that can 
coupling the inabmty t0 CatCh bUgS ariSlng fr ° m unantici P ated capacitive 

No Loads on Off-chip Inputs 

Charge retention analysis does not model wavering off-chip inputs; there are no 
edges in a net transition graph corresponding to off-chip inputs which suddenly un- 
dergo large loads. Therefore off-chip inputs must be considered immune to on-chip 
transitions. For example, Gnd and VDD are considered constant; even if a heavy 
load is placed on them this load cannot be detected anywhere in the circuit. The 

f am f ^ ^n/° r the 0t , hef ° ff " Chip inpUtS - l d ° not know if this is a significant prob- 
em for MOS circuits (,.«., if circuits have failed because designers didn't anticipate 
oads causing off-chip inputs to waver), but I know of no system which addresses 

tnis problem. 

2.6 Summary 

This chapter presented the the component model, signal model, and network model 
ot bilica Pithecus. These models are known collectively as a circuit model. The 
bugs which can and can't be modelled within this model were discussed. 

This chapter introduced the notion of net behavior. The idea of focusing analysis 
on nodes and the nets they are members of during settling is novel. Previous 
researchers have looked at the nets a circuit is partitioned into during settling 
without investigating what the partitioning looks like from a node's point of view 
The power of this idea in the next chapter appears in the next chapter. 
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Chapter 3 

Multilevel Verification 



Circuit behavior can be described at different levels of abstraction ranging from the 
analog level to the functional level. Multilevel verification proves that two different 
levels of behavioral description describe the same behavior. The more abstract level 
description of a design's behavior is called its abstract behavior, the less abstract 
level description of a design's behavior is called its concrete behavior. 

Multilevel verification has two parts: abstraction and validation. Abstraction 
lifts the concrete behavior level to the abstract behavior level. The resulting de- 
scription is called the abstracted behavior. Validation is the comparison of the 
abstracted and abstract behaviors. An implementation meets its specification if the 
comparison succeeds, otherwise the implementation is declared incorrect 

This two step scheme, abstraction followed by validation, makes the dependence 
of verification on the abstraction function explicit. The abstraction function serves 
two purposes: approximation and structure definition. Which purpose is served 
depends on the descriptive level of the concrete behavior. At the lower levels, such 
as the signal level, abstraction replaces "physical reality" with gross approximations 
(i.«., digital values). At this level, the accuracy of verification is bounded by the 
accuracy of the abstraction function. For higher descriptive levels, such as the 
digital level, abstraction replaces data structures with the values they denote For 
example, when abstracting from the boolean level to the arithmetic level, a vector 
of booleans is abstracted to a number. 

Not all elements of the concrete domain map into elements of the abstract do- 
main. The abstraction function is responsible for returning an error value on ele- 
ments which do not map. For example, the abstraction of a signal that can not be 
abstracted to either or 1 must be an error value. One role of constraints is to 
specify that a design's inputs and outputs are always abstractable. For example 
at the signal level, the constraints such as no-drop, falls-first, overpowers 
and control all exist solely to ensure that input and output signals abstract to 
non-error values. 
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The difficulty of validation depends on the descriptive level. Digital validation 
consists of proving two digital expressions are equivalent. Except for complex com- 
binational circuits such as ripple carry adders, the formulas are small and easily 
compared. Functional validation, which must compare formulas in domains richer 
than boolean algebra (e.g., arithmetic), is hard to do. 

A design is digitally verified when its signal behavior has been verified against 
its in ended digital behavior. Likewise, a design is functionally verified when its 
digital behavior has been verified against its intended functional behavior. We 
are primarily concerned with digital verification. The methods to be proposed for 
digital verification have been implemented, but no such claim is made for proposed 
methods of functional verification. 

♦ a^V advantage of mu ^level verification is that the description of the in- 
tended behavior itself can be verified. Abstract behavior at one level is concrete 
behavior at the next abstraction level up and can itself be verified. This is a powerful 
mechanism for verifying the behavior of a design over many levels of description. 

This chapter has four sections. In the first section some of the levels of behav- 
ioral description are discussed. A brief discussion of the different descriptive levels 
of time is included in the first section. The second section describes multilevel ver- 
ihcation. It delineates issues and presents my theory of multilevel verification. The 
third section focuses on digital verification and functional verification. The chapter 
concludes with a summary. 

A given circuit can be described in a variety of ways. For example, a circuit can 
be described at the signal, digital, gate, or functional level. Each level hides details 
of the lower level.* A pictorial example appears in Figure 1.1. The higher levels of 
description are more concise than the lower levels. 

We are concerned with the signal, digital, and, to some degree, functional de- 
scriptions of circuits. The signal level describes a circuit's function in terms its 
nput and output signals. The digital level is similar to the boolean level, but with 
the inclusion of the operand float and the function join. The functional level is 
denned by the user. 

The signal level views a circuit as a map from input signals to output signals. 
The signals at state nodes are both input signals and output signals. A signal is what 
appears on your oscilloscope when you stick the probe on a node. It is crucial that 
signals, rather than voltages at some point in time, are employed as the primitive 
values operated on by circuits. Signals encompass time, therefore any method for 
abstracting signals into digital values must consider time. 2 If just voltage at some 
point m time were used, then a separate mechanism would be required to handle 
time. A separate mechanism wo uld make the formalization of verification much 

'The different descriptive levels do not form a linear hierarchy. For example, a digital design that 
uses Instate buses cannot be abstracted to the gate leveL 

3 Even if an abstraction function ignores time, it must do so explicitly. 
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harder. The following chapters discuss in detail the derivation of a circuit's signal 
behavior from its structure. 

The digital level has three primitive values: 0, 1, (called boolean values) and 
float. It has the standard boolean functions for operating on boolean values and 
the operator j oin. Join is an n-ary function which returns float if all its arguments 
are float, returns 1 if all the non-float values are 1, returns if all the non-float 
values are 0, and otherwise signals an error. Join and float are used to model 
circuits containing tristate devices. 3 

The functional descriptive level is very abstract. Its primitive types and op- 
erations are defined by the user. For example, the primitives may be numbers, 
pointers, or sets. The corresponding operations might be addition, dereferencing 
or union. This level is characterized by being very close to the application the de-' 
signer is creating a circuit for. Specifying the behavior of a circuit at this level is 
very concise and simple. 

3.1 A Formal Model of Verification 

We first introduce notation. Design is the object whose behavior is to be verified 
Its behaviorjn some domain D is written B D (Design). Design's inputs are are 
written t D - »i D ,...,t no where t D € D n . Its outputs are the result of applying 
its behavior to its inputs: b D = B D (Design)(i D ) = o lD ,...,o mo where b D e D« 
ihe two domains of a gl ven multilevel verification are called con and abs. Multi- 
level verification relates B eon {Design) and B aht {Design). We will often leave the 
domain descriptor off the inputs and outputs and just write t and o. When domain 
descriptors are elided the eon domain is assumed. 

SPEC, the specification of Design, is what it to be proved about Design 4 P 
are the set of promises about how the design will be used, they restrict the class of 
allowable inputs to Design. P corresponds to what we have been calling constraints 
Design is verified with respect to its specification SPEC and constraints P when 
the verification condition 



v i€D»{( A ?(*)) => SPEC(t,B D (Design)(i))} 



is shown to hold. 



The hardware digital level i, the abstraction level espoused in Introduction to VLSI System, 
[ ^Z L T\ V ^ b0 ° k PrOV ^ 8 * methodol o«r <>f *«*» A-.-, proved way. of connect^ 
from tW t er i W ^/T" th l digital ab8tractio *' For example, a designer who learned only 
from the* book would not create a bootstrap driver (Figure 12.1) or a three transistor ram (Figure 

*SPEC has a very specific form when multilevel verification is performed, as will be seen below. 
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Design is a circuit with one input « and one output o ranging over time-varying 
signals S. B s {Design) : S -> S 



Design 



Vi<=s{stable(i) => stable(o)} 



• Design is a nand gate. 



i1 



i2 




^«'i,«a€{true,/al»e}{t2 ^ (o = not(t'i))} 

• Design is an adder whose inputs t and output o range over the natural 
bers N. In this example P is empty. 



num- 




V «i.fj€Jv{o = »i + t 2 } 



Figure 3.1: Example Verification Conditions. These are all examples of monolevel 
verification. 
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Examples of verification conditions are shown in Figure 3.1. The first example 
checks properties about signals in to and out of a circuit. It specifies that if the 
input signal is stable then so is the output signal. The next example is the statement 
that if you hold one of the inputs to a nand gate high then the gate looks like an 
inverter to the other input. The third example is the statement that some device 
is an adder. 

All of these are examples of what we call monolevel verification. In monolevel 
verification only one level of behavioral description is handled. Monolevel verifica- 
tion attempts to prove specific properties of the behavior of a device. 

Multilevel Verification 

In multilevel verification there are two different levels of description for Design, 
B eon (Design) and B ait {Design), which must be related. The relationship between 
the two domains is given the by abstraction function ABS. It maps elements of con 
into elements of 065. There are some elements of con for which ABS is undefined. 
We make ABS a total function on con by adjoining a special "error element" _L to 
ABS's range as a target for ABS when it would otherwise be undefined. Specifically, 
ABS : con => abs + {!_}. ABS is defined for some input i when ABS(i) € abs. 
Any element of con for which ABS returns _L is said to be invalid. 

When discussing specific domains, ABS may be subscripted with its types 
For example, when the context isn't clear, the abstraction function from signals 
S to tnstate values T will be written ABS S _ T . Finally, we also have ABS(t) = 
ABS{i l ),...,ABS(i n ) u 

Given B eon (Design) and ABS, B abt [Design) is projected from B eon (Design) by 
the following formula: 

V*con»{ABS(B eon [Design)(i)) = B abt (Design)(ABS(i))} 
wherever ABS(i) and ABS(B eon {Design)(t)) are both defined. 

This relationship can be expressed as a commutative diagram (Figure 3.2). The 
key point is that B abt (Design) does not exist independently of ABS. For example, 
if ABS returns _L everywhere, then B abt (Design) is nowhere defined. 

We can now define multilevel verification. Given B eon (Design) and of De- 
sign's intended abstract behavior IB ab .(Design), we wish to show IB abt (Design) = 
B abt (Destgn): 

Definition: Multilevel Verification is Verification where the specification is of the 
form 

ABS(B eon (2? M t0n)(t e(m )) = JS o4 ,(Z> M t0n)(ABS(t e(m )). 

where IB abt (Design) is the intended 065 level behavior of Design and where both 
sides of the equation are defined. 
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A 

i 



abs 



ABS 



A 
I 



con 



Babs (Design) 



B cori (Design) 



A 

-►o 



abs 



ABS 



A 

"► O 



con 



!r/\!f p rn ? nS n P , betWeCn *-(*"•*») and ^(Design). Given 
fit *r (DM, ^>\ ^^"W is P~J«tad from B eon (Design) accord- 

ABSf II (n ^T' ^^ C J 0mmutativit y need only hold when ABS(i e<m ) and 
&BS(B eon (Destgn)(i eon )) are defined. ; 



Putting everything together yields 

Vi 6eon »{ /^p(t) => ABS(£ C(m (I^n)(i)) = JS.».(Z>eai^n)(ABS(f))} 
as the verification condition for multilevel verification. 

The Role of P, and Automatically Generating Constraints 

An important part of the above proposition are the promises P, also called con- 
^roleC " ^ ° f ^^^ ^^ t0 * design - The constraints have 



1. To ensure valid inputs (i.e., that ABS(f cen ) is defined). These are called input 
constraints and are assumed to be met. 

2. To ensure valid outputs (i.e., that ABS(B abt (Design)(i eon )) is defined). These 
are called output constraints and can be automatically generated. 

3. To specialize behavior. These are called logical constraints and must be pro- 
vided by the designer. 
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Input constraints are assumed to be met by the environment in which a design 
operates. Inputs are assumed to be valid because they either come from the outside 
world in which case we must assume they are valid, or they are outputs from other 
verified designs, which guarantees they are valid. For example, consider a circuit. 
Only inputs from off-chip must be assumed to be valid, all other inputs are valid 
because they are outputs of verified subcircuits. 

The constraints which ensure outputs are valid can be automatically generated. 
Given a representation of ABS(B ab ,(Design)(i eon )) that makes error conditions ex- 
plicit, constraints are generated which ensure the conditions causing the error condi- 
tions never arise. For example, in the signal domain, this how threshold constraints 
are generated. When an input signal suffering a threshold drop causes an invalid 
output signal the signal will be constrained from suffering a threshold drop The 
constraint guarantees the output will not be invalid (at least from this particular 
causej. An explicit example is presented below. 

The constraints which specialize the behavior of a design must be provided by 
the designer. They cannot be assumed or automatically generated. For example, 
the logical constraints a designer must provide to Silica Pithecus to declare certain 
inputs are mutually exclusive. The constraints specializing behavior must be em- 
ployed when deriving a design's behavior from its structure. Otherwise, behaviors 
which don't arise will be predicted. 

The Big Picture 

Three major ideas lurk in the verification condition for multilevel verification. They 

• The relationship between different behavioral descriptions. 

• The relationship between structure, function, and context. 

• Intentional analysis. 

The first item, the relationship between two different behavioral descriptions 
has been discussed in detail. 

The introduction of this dissertation made the claim that structure alone does 
not determine function, but that structure and context do. Referring to the ver- 
ification condition of multilevel verification, we can now state more precisely the 
relationship be structure, function, and context: P is the context that the structure 
Design must have to exhibit behavior IB abt {Design). 

Intentional analysis says that what must be derived from a design's structure is 
not its behavior, but the abstraction of that behavior. That is, the important item 
.s not B eon (Destgn), but ABS(B eon (D e stgn)(i eon )). As a result, the full behavior of 
Design need not be generated. For example, the focus of Silica Pithecus's behavior 
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generation is not to generate signal behavior, but to generate constraints which 
ensure that whatever the signal behavior is, it will be abstractable. Much of the 
signal behavior is left symbolic (,'.«., in terms of the names of signals rather than 
the signal values themselves). 

We now look at functional and digital verification in detail. Functional verifica- 
tion will be presented first to get the reader accustomed to the ideas and notations. 

3.2 Functional Verification 

The application of the design (e.g., numbers, sets, pointers) determines the type of 
abstraction and functional validation. A given design may support many domains 
at once. There are two major problems associated with functional verification: 
validation and accurate specification. In the following we will concentrate on just 
the arithmetic domain (integers and addition) to illustrate functional verification. 
Validation, the comparison of abstracted functional behavior and intended func- 
tiona behavior, is difficult to do. A significant amount of knowledge of the func- 
tional domain must be employed. 5 Embedding in a verifier the knowledge needed 
is hard because it is hard to a priori determine which knowledge will be useful: 
embedding everything is virtually impossible. 

The second problem with functional verification is accurately specifying be- 
haviors. A specification must be well defined before validation can be done. For 
example, consider the digital specification of a 16 bit adder for adding unsigned 
..integers, called A and B. Each integer is represented as vectors of bits (the stan- 
dard representation). There are several choices possible for handling overflow. The 
overflow bit can be ignored, it can be appended to the sum to yield a 17 bit result 
or it can be returned separately to signal an error condition. 

Even though each of the three methods of handling the overflow bits still results 
in an adder, only one, the second, can be specified as A + B (for A B < 2 16 ) 
The others which are far more common, must be specified differently, for example,' 
(A + B) mod 2" for the first method. (There's even residual vagueness in the spec- 
ifications gl ven. The function ♦ is polymorphic, its behavior depends on the types 
of its operands. A more accurate specification is A + int B and (A + int B) mod 2 16 .) 

Example: An Adder Cell 

Consider a full adder (Figure 3.3). It has three inputs A, B, and Carryin, and 
two outputs called Carryout and Sum. The Adder Cell is composed of gates, 
therefore its concrete behavior is expressed in the boolean domain. We with to 
show the adder cell adds number s, therefore its abstract behavior is expressed in 

5 Also, these domains are very complex and formulas in them may be undecidable. 
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Sum 



Carryin 




Carryout 



Figure 3.3: A Full Adder 



the arithmetic domain. The two domains are called B*, for boolean values {true 
and false) plus vectors of booleans, and W, for the whole numbers: 

Aon = {true, false, [b Q , ..., b n }} 
Dab* = W (Whole Numbers). 

Our abstraction function is 

ABS(true) = 1 

ABS(false) = 

ABS(fb , ..., b n ]) = Eo<,< n YABSibi) 

The Adder Cell's concrete behavior is 

£ij.(Adder Cell) = A a b c . [sum(a, b, c), carry(a, b, c)]. 

The Adder Cell only accepts Booleans, it does not accept vectors. This fact is 
expressed by the input promise 

Boolean{i u i 2 ,i 3 ). 
The Adder Cell's behavior in the arithmetic domain is intended to be 

IB w (AdderCell) = Aabc.a + b + c. 
The Adder Cell's specification is therefore 

ABS{{\ a b c . [sum(a, b, c), carry(a, b, c)])(» lf »,,*,)) 
= (Aabc.a + b + c)(A J B5(t 1 ),^55(tj),^55(» 3 )) 
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and the verification condition for verifying the Adder Cell is 

VieB* {Boolean(i x , t 2 , 13) =► 
ABS({\ a b c . [sum(a, b, c), carry(a, b, c)J)(ti,*a,i,)) 
= (Aabc.a + b + c)(^BS(t 1 ),AB5(t,)MB5(t 3 ))} 
Using beta-reduction, the above equation can be simplified to 

V%€B* {Boolean(i 1,12,13) => 

ABS(sum(ii,t2,i 3 )) + 2ABS(carry(i u i 2 ,i 3 )) 

= ABS{ii) + ABS(i 2 ) + ABS(i 3 )} 

This equation can be shown to hold by exhaustively enumerating all combina- 
tions of the inputs, thereby verifying the design of the adder cell. 

An example of hierarchical verification in the arithmetic domain appears in 
Chapter 10. That example verifies a multi-bit adder built from Adder Cells. 

3.3 Digital Verification 

Digital verification verifies that the signal behavior of a circuit correctly implements 
the intended digital behavior of the circuit. 5, the signal domain, and T, the 
tnstate domain, are the two levels of behavioral description of digital verification 
As mentioned previously, signals are characterized as mapping time into a voltage 
and a strength, S : time - (voltage x strength). The tristate domain is {false, 
true, float}. We have ABS S -. T : S - T. In this section we assume some 
magic function which yields B s (Design) for any Design. Later chapters discuss 
how B s (Design) is generated. 

This section uses as examples only combinational circuits (i.e., combinations of 
gates) with electrically isolated inputs. This simplifies the abstraction function and 
allows us to concentrate on the process and major ideas of digital verification. Later 
chapters handle circuits with both state and non-electrically isolated inputs. Signal 
strength is also ignored here as it is irrelevant for the verification of combinational 
circuits. 

The abstraction function we will use in the example is 

ABS = A s . VTB(voltage(s(t f ))) 
VTB = A v . v > 3.5 -♦ true, 
v < 1.5 -»• false, 

-L. 
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Figure 3.4: A Minimum Sized Inverter. To ensure that the output of this device 
is valid we must guarantee the input does not suffer a threshold drop. This device 
has one input signal and one output signal. 



ABS accepts a signal 5 and turns its final voltage into a boolean value using the 
rule that voltages above 3.5 volts give true, voltages less than 1.5 volts give false 
and other voltages give _L. 

Silica Pithecus is given the schematic Design, a specification of Design's in- 
tended tristate behavior IB T (Design), and the logical constraints on it Design. We 
wish to show IB T (Design) = B T (Design). The verification condition for digital 



Ws{ A ?(*) => ABS{B s {Design)(t)) = IB T (Design)(ABS{t 



P€P 



))} 



where P = Input Constraints U Output Constraints U Logical Constraints. 

ine input constraints, which guarantee that inputs are valid, are assumed The 
output constraints, which guarantee outputs are valid, are automatically gener- 
ated Only one type of constraint, the threshold constraint, is needed for verifying 
combinational circuits with isolated inputs. The logical constraints are given. 

Example: A Minimally Sized Inverter 

Consider a minimally sized inverter (Figure 3.4). We wish to prove that this device 
computes the boolean NOT function. The inverter takes one input signal and yields 
one output signal. 

tv, JJlS rOC r i ? re i Which generates B s (Design) from Design uses the knowledge 
that ABS only looks at the final value of a signal. The procedure yields 

B s (Inverter) = 

A in . 
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Xt. 
t = t f -+ 

(voltage(m(*)) = 5 -► 1, 
3.5 < voltage(m(t)) < 5 -♦ 1.66, 
1.5 < voltage(m(*)j < 3.5 -► X, 
< voltage(m(*)) < 1.5 -+ 5), 
X 

as the signal behavior of the inverter. This is read as follows. The Inverter takes a 
signal m and returns a signal, call it out. For any time not equal to *,, out returns 
X, meaning an unknown voltage. When time is t h out returns a voltage based 
upon the circuit model («/. Chapter 2) and the input voltage. No more detail than 
this is necessary to verify the inverter. 
Inverter's intended boolean behavior is 

IB T (Inverter) = X a . NOT(a). 

Finally we have the constraint that Input is valid. The constraint guarantees that 
Input s fina i vo i tage is either above 3 g ^ or ^^ ^ ^ ^ ^^ ^ 

written <ts 

VV(voltage(in(t f ))) 
where VV stands for Valid Voltage. 
Invertlr- 11686 ^^^ W wra PP ed to 8 et ^ to create the verification condition for 

V, € s{^(voltage(i(*/))) =► 

ABS((A in . 
Xt. 
t = f-+ 

(voltage(m(*)) = 5 — 1, 
3.5 < voltage(t'n(t)) < 5 -> 1.66, 
1.5 < voltage(m(«)) < 3.5 -♦ X, 
< voltage(m(*)) < 1.5 -► 5), 
X 

(0) 

= (Aa.N0T(a))(ABS(»))} 

This equation can be simplified by using beta-substitution and distribution of func- 
tions across the arms of the conditional. The result is 

VfesfVVfvoltageM*/))) => 
voltage^*,)) = 5 -► false, 
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DO 

3.5 < voltage^)) < 5 -+ J_, 
1.5 < voltage(i(t/)) < 3.5 -► _L, 
< voltage(i(«,)) < 1.5 -► true 
= N0T(ABS(»j) } 

The input constraint is used to eliminate the third clause. 6 It guarantees that 
the predicate of the third clause will always be false. Throwing out the third clause 
yields 

Vies{VV(volti&(i(t f ))) =» 
voltage(x'(t / )) = 5 -► false, 
3.5 < voltage(t*(« / )) < 4.5 -► J_, 
< voltage(t(i / )) < 1.5 -► true 
-N0T(ABS(»))}. 

The second clause shows an error condition which arises when the final value of 
the input signal is between 3.5 and 5 volts. This condition is indicative of a threshold 
drop The error condition is prevented by generating the constraint that input 
cannot suffer a threshold drop. The constraint is written no-drop(voltage(»(*,))). 
This constraint subsumes V^(voltage(t (*,))). Posting this constraint yields 

V,65{no-drop(voltage(i(« / ))) => 
voltage(»(t/)j = 5 -► false, 
< voltage^*,)) < 1.5 _♦. true 
= N0T(ABS(»)) } 

Because voltage^*,)) = 5 implies ABS(i) and it is the only clause to do so, 

^ 1 ! h " ? rmef Wlth tKe latter ' SimiIarIy ° < volta S e (*'('/)) < 1-5 implies 
NuqArJb(tj) and it, too, is so replaced. These substitutions yield 

V,g5{no-drop(voltage(»(t / ))) => 
ABS(t) - false, 
M0T(ABS(0) - true 
= N0T(ABS(t)) } 

Finally, the upper conditional is recognized as an idiom for NOT and rewritten to 

V, €5 {no-drop(voltage(t(i/))) => 
M0T(ABS(t)) 

= N0T(ABS(j)) } 
which is true. 



6 \ a t . t «;!! n ! >1 * lne, } tati r th * constra J int » U8ed to P"™* the third clause from even being generated. 
ItMMr to explam how to get rid of something than to explain why it's not created in the first 
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3.4 Summary 

There are many levels of description for the behavior of circuits. Multilevel verifi- 
cation is the successful comparison of the same behavior at two different levels of 
description. The abstraction function was the key to relating the two behavioral 
descriptions. 

The verification condition for multilevel verification made explicit many informal 
notions Presented m the introduction of this dissertation. These include the relation- 
ship between different behavioral descriptions, the relationship between structure, 
function, and context, intentional analysis, the role of constraints, and a method 
tor automatically generating constraints. 

An idealized scenario of how Silica Pithecus verifies a combinational circuit 
was presented. This scenario stressed the abstraction of signals and the automatic 
generation of constraints. 



Chapter 4 
State and Time 



Circuits with state are more complex than combinational circuits. Unlike combina- 
tional circuits whose outputs can be predicted solely from the final values of their 
input signals, the outputs of circuits with state depends on their input signals' en- 
tire waveforms. This chapter motivates and explains the abstraction function used 
by Silica Pithecus which enables Silica Pithecus to verify circuits with state. This 
chapter also develop the input constraints that ensure that all output signals are 
abstractable. 

There are two properties we desire of the abstraction function. First, we want 
the abstraction function to be deterministic. That is, it should guarantee that the 
same inputs (after abstraction) yield the same outputs (again, after abstraction). 

Second, we want to be able to symbolically predict, for all valid states and in- 
puts of a circuit, the final state of the circuit. The abstraction function found will 
therefore require that nodes storing state are not corrupted. 1 State and corruption 
are technical terms. State is stored charge that affects the outputs of a circuit 
Corruption is not so easily defined, although it does correspond to the usual in- 
tuitive idea (Corruption is defined below.) There are pathological circuits that 
are designed to corrupt state. Such circuits cannot be verified by Silica Pithecus 
Fortunately, such circuits are rare. 

Just as the abstraction function given in the previous chapter required threshold 
constraints to ensure outputs were valid, the abstraction function we are looking 
for will require timing constraints to ensure outputs are valid. There are two types 
of timing constraints, stable-after constraints and falls-first constraints. A 
stable -after constraint requires a given signal to be stable after some other signal 
is asserted A falls-first constraint requires a given signal to fall before some 
other signal changes. These a re the only constraints needed to ensure stored charge 

'The general, and correct, statement is that nets which store state are not corrupted. A node is 
the degenerate case of a net with only one node. We will soon talk in terms of both nets and 
nodes storing charge. 
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Figure 4.1: A NAND Gate. When the upper transistor "stores" a the charged 
stored on the lower transistor can be safely corrupted (i.e., C2. can glitch). 

is not corrupted. A control signal is a signal that must remain asserted once it is 
asserted. That is, control(N.) is shorthand for stable-after(N„ N.). 

Silica Pithecus treats state bits as both inputs and outputs of a 'circuit The 
abstraction procedure is applied not only to the output signals of a circuit, but also 
to its state signals as well. 2 The signals of nodes which do not store state, do not 
gate transistors, and which are not outputs of circuits are not abstracted. Such 
nodes, called connection nodes, serve only as vias for information flow. Because 
connection nodes are never abstracted, the charge on them can be, and often is, 
freely corrupted. 

This chapter has nine sections. The first section discusses locating a circuit's 
state nodes. The second section defines corruption. The third section develops the 
idea of deterministic abstraction functions and shows why the abstraction function 
of the previous chapter is nondeterministic. The fourth section gives the abstraction 
function used by Silica Pithecus. The fifth section presents the representation which 
makes invalid signals apparent. It also shows how constraints ensuring signals are 
valid are issued. The following sections expand on the fifth section in different 
ways. The sixth section discusses some implementation issues. The seventh section 
present* a fairly complicated example. The eight section generalizes the methods 
to handle circuits containing transistors with different (positive) thresholds. The 
chapter ends with a summary. 

4.1 Finding State in a Circuit 

A node storing charge is a state node if its stored charge can affect a circuit's output 
behavior. State nodes a ppear in memory cells, shift registers, and latches. 

A state signal is the signal at a node storing state. 
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Figure 4 2: A 4-way Selector. The charge stored on the internal nodes is often 
corrupted during settling. The internal nodes are called connection nodes. 



It is difficu t to accurately assess which stored charge represents state. Data 
dependencies allow what would otherwise appear to be state to be freely corrupted. 
For example, consider an nMOS NAND gate with latched inputs whose upper tran- 
sistor is storing- a (Figure 4.1). In this case the stored charge on the lower gate 
can be corrupted (by C2. glitching) without affecting the outputs of the NAND 
gate. Silica Pithecus does not consider such data dependencies when locating state. 
If there is any point in time at which a node stores state, then Silica Pithecus con- 
siders the node to store state at all times. This approach is overly conservative, but 
no problems have yet been encountered using it. 

State nodes are statically discovered by performing a recursive tree scan of the 
net behavior equations of a circuit. The scan starts from the output nodes of the 
circuit. For each node N in the scan, JV's possible nets are examined. If a net is 
not driven then all its dominant nodes are state nodes. The dominant nodes of a 
net are those whose capacitance overpowers* the capacitance of the other nodes in 
the net If a net contains an input node then the input node is the only dominant 
node of the net. Except for nets containing inputs nodes, a net can contain an 
arbitrary number of dominant nodes. The scan is repeated for each new dominant 
node found and for each node mentioned in the predicates of N. The scan ends 
when no new state nodes are found. 

Nodes which don't store state and whose signals don't appear in the predi- 
cates of net behavior expressions {i.e., don't gate transistors) are connection nodes. 
Connection nodes can be freely corrupted. For example, consider a 4-way selector 
(Figure 4.2). Assume that the four inputs are driven and that both A»fo) and 
B t (t.) are not asserted. If, during a computation, A 6 and B» waver before returning 
to being unasserted, then the internal nodes will be corrupted. This corruption has 
no effect on the output of the selector. 

3 Silica Pithecus defines overpowers as ten times greater. 
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4.2 Corruption 

Let net be some final net.* We want to be able to predict the voltage of any node 
in net solely from the initial state of the nodes in net. If net contains driven nodes 
then the prediction can be based solely the driven nodes. If net contains no driven 
nodes then the final voltages can be precisely predicted from initial voltages if and 
only if, during settling, no nodes in net shared charge with nodes not in net. When 
a final net contains nodes which have shared charge with nodes not in the final net, 
we say that the net has been absolutely corrupted. A later section discusses avoiding 
corruption. 



Example: Latched Inverter Cell 

For example, consider again the Latched Inverter Cell (Figure 2.2). Its S node 
has three possible nets, [S], [S, Out, Vdd], and [S, Out, Vdd, Gnd], all of which 
can be final. 5 When S^t,) is either [S, Out, Vdd] or [S, Out, Vdd, Gnd] Thevenin 
equivalents are used to calculate the voltage at S. When S„ t ( t/ ) = [S], then absolute 
corruption may have occurred. Consider the computation sequences of Figured 3 
In the upper figure S^tf) (= [S]) is not corrupted because S has not shared charge 
with any other nodes. (Although it began connected to other nodes, it did not share 
charge with them. Remember, it is assumed that circuits start out at steady state ) 
In the lower figure [S] has been corrupted because it momentarily shares charges 
ro w^ VDD * Another P ath ( not sh °wn) which corrupts [S] is [S, Vdd, Outl 
-MS, Vdd, Out, Gnd] - [S]. In this case S shares charge with Gnd before being 
isolated. * 

Absolute corruption is too strict a notion. Instead, a less strict form, simply 
called corruption, is more useful. A final net is corrupt if its dominant nodes have 
shared charge with nodes not in the net. Corruption differs from absolute corruption 
m that the charge sharing of non-dominant nodes is not considered. The voltages of 
nodes ma net whose non-dominant nodes have uncertain charge can be calculated 
with sufficient accuracy for verification. 

Dominant nodes cannot be allowed to share charge with any extra nodes, re- 
gardless of their capacitance. They might lose enough charge a little at a time such 
that an accurate prediction of voltages on final nets is impossible. 



'Review the section on signals in Chapter 2 for the definition of final net. 

6 Not all of a net's possible nets can be final Steady state logical constraints dictate that although 
certain nets can occur during settling, these nets can't occur at steady state. 
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Figure 4 3: Computation Paths. These are two possible computation paths of the 
Latched Inverter Cell's S node. In the upper path S begins connected to Vdd and 
Out Then the input to the inverter goes low and then Latch falls isolating S. In 
the lower path S begins isolated. Then Latch goes high (while In is asserted) then 
falls, leaving S isolated. The labels of the edges indicate which signal causes the 
transition and the signal's direction of change. 
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fZt, U f ° 1 n - de * er o mni8 i tlc Abstraction. This figure depicts two different exper- 
iments (trials 1 and 2 trials 3 and 4). Each experiment shows equivalent inputs 
giving different outputs. "Non-deterministic behavior" refers to this phenomenon 



4.3 Deterministic and Nondeterministic Abstrac- 
tion Functions 

From a theoretical viewpoint, the major problem of the abstraction function of the 
previous chapter, A s . VTB(voltage( a (^))), is that it projects a non-deterministic 
B T A behavior is non-deterministic when the same inputs can give different out- 
puts Two idealized experiments with the Inverting Latch (Figure 2.2) will make 

his clear Consider Figure 4.4, which shows four different sets of inputs applied to 
the Latched Inverter Cell, and shows the S. which results from the inputs Both 
experiment* show the boolean behavior of this device giving different outputs for 
W S Z5 n f ," ^ 6rSt ex P* riment ABS(In.) and ABS(Latch.) are both 0, 

U ^ B( ' ! S !^ er l or °- In th « second pair of experiments, ABS(In.) is 1 and 
ABS(Latch,) is 0, but again ABS(S,) is either 1 or 0. 

There are two ways to project a deterministic B T . The first is to have the 
abstraction function differentiate between inputs which cause different outputs, ." e 
guarantee the inputs will be different when the outputs are different. The second, 
and more natural method, is to declare certain output signals to be invalid. Silica 
Pithecus takes this approach. Its abstraction function will declare S. in trials 1 and 
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4 to be invalid. As a result, when verifying the circuit, Silica Pithecus constrains 
Latch, from ghtching and constrains In, from changing before Latch, falls. These 
constraints prevent the invalid signals from occurring. 

Circuit designers will recognize the first pair of runs as exhibiting what is known 
as a hazard and the second pair of runs as exhibiting a "race." Hazards occur 
when control signals go through too many transitions during settling. The standard 
example (exhibited in the figure) of a hazard is a control signal which begins at and 
ends at 0, but goes through two transitions (up and down). 8 Because the transitions 
of a control signal affect a circuit as much as the value of a control signal, the extra 
transitions cause the circuit to end up in the wrong state. 

Races occur in MOS technologies when the signal isolating an undriven net and 
the signal changing the value of the net both change during the same computation. 
The order m which the signals change affects the final state of the net. If the net 
is first isolated, its final value will be different than if it is changed before being 
isolated. For example, Latch, of the Latched Inverter Cell must fall before In 
changes in order to isolate [S] before it is changed by In,. When In, and Latch, can 
change on the same computation there is a race condition. 

Hazards and races cause corruption. If hazards are outlawed, and races carefully 
ordered then corruption will not occur and a deterministic B T results. The ordering 
of races is presented below. The signals which Silica Pithecus declares to be invalid 
are precisely those which represent (potentially) corrupted state. 

4.4 The Abstraction Function 

The abstraction function has the desirable properties that it projects a deterministic 
U T and it places timing constraints on inputs to ensure outputs are valid. 

4.4.1 Valid Signals 

The rules for valid signals are presented below. If all output signals (state signals 
are considered output signals) are valid then no state nodes are corrupted. A signal 
is valid when 6 

• Its strength does not decrease after its voltage changes. 8 

•I often think control signals are called .uch not because they control things, but because they 
themselves must be controlled. »w»use mey 

'orSr t rt g es WhiCh * *"° '^^ " * ™ ^ Ch * nge *"' "*" th * »» Timin * constraint. 

'Jf^i?. 11 !? th *- lea ? " 8trictiv « role fOT «"<*** fr^om from corruption. There are a range 
of rules, from .unple to complex, that can be used for avoiding corruption. Simpler rule, a£ 
easxer to check than complex rule,, but they give more frfa. negative, "han compkx conditio! 
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• Its final voltage is less than 1.5 volts or more than 3.5 volts. 



The two rules are called the strength rule and voltage rule, respectively. 

Sources of corruption can divided into two classes: Momentary Expansion Cor. 
ruptton, and Driven Corruption. Momentary Expansion Corruption occurs when a 
net expands and then contracts. Except when the net contains driven nodes both 
before expanding and after contracting, the expansion and contraction shows up as 
an mcrease in strength followed by a decrease in strength. An example of this type 
of corruption is shown in the lower half of Figure 4.3. We conservatively assume 
that the voltage of signal always changes when its strength increases. 9 The Strength 
Kuie prevents momentary expansion corruption. 

The stable-after constraint is used to prevent momentary expansion corrup- 
tion It prevents a net from shrinking after it has expanded. The form of the 
constraint is stable-af ter(X.,Y,), which means that after X, is asserted, Y. must 
remain stable "> It also implies that Y. must be stable as X. is asserted (i.e., as X. 
rises, in nMOS). control(x.) is shorthand for stable-af ter(x.,x.). 

Driven Corruption occurs when the initial strength of a signal is oo and the 
voltage of the signal changes before the strength of the signal becomes finite. For 
example cowidermg the Latched Inverter's S node again, the sequence [S, Vdd, 
Out, Gnd], [S, Vdd, Out], [S], is an example of Driven Corruption. Driven Corrup- 
tion is prevented by the Strength Rule which dictates that once a signal's voltage 
changes the signal's strength cannot decrease. 

♦i. J*? * al l 8 ^ r ? \ constraint » ™* d ^ P^ent Driven Corruption. It ensures 
that strength falls before voltage changes, f alls-f irst(X„Y,) means that if X. 
must fall before Y, changes. 

The two constraints, falls-first and stable-after, are collectively called 
timing constraints. The two constraints collectively outlaw hazards and order races. 
Races are ordered such that undriven nets are isolated before they are changed. We 
call the ordering of races prescribed by the Strength Rule the natural ordering. 

tvltt^* WSU . Ch08e ? U ^V™* 1 *" rak Whkh Vwifi " ™*-drwi* Interested reader, can 

JE£5K£!" on own ' saka pit w h - acco " te - poMibfe with dob * * 

"ht • dtu^^^c^^ to aUow sm ~ pith - to b - j ~ -— 

'SS^aJU ^ aU ° Wed K b r treatin S th « "* rtio » ^ X. as taking some finite amount of time 
rather than the assertion being instantaneous If we take "after X. is asserted" to mean 'after X. 

«^SL"3ff ^ "^ Y ' " be " table wWk X ' k h ^ *~ rt « d ' *- b ~ h i 



10 



4.5. ISSUING CONSTRAINTS 75 

4.5 Issuing Constraints 

The representation of signal behavior makes error conditions (i.e., invalid signals) 
explicit so that constraints guaranteeing valid signals can be automatically gener- 
ated. The representation is based on computation paths and net transition graphs. 
Constraints are generated directly from each state node's net transition graph. 

Unlike threshold constraints which always apply, timing constraints condition- 
ally apply. That is, only under certain conditions must X, fall before Y. or must 
X, be stable after Y. is asserted. Associated with each timing constraint is a pred- 
icate on the state of the circuit which controls the application of the constraint. 
Only when the predicate is true must the constraint hold. For example, in the 
scenario of the first chapter had the constraint Latch* =► overpowers ([In], fS] ) 
The predicate is "Latch*" and the constraint itself is "overpowers ([In] 7 ,[S] ) " 

The elements of the predicates are boolean signals, rather than boolean values, 
and are meaningless unless unless their time component is quantified. We conser- 
vatively state that a predicate is true if there is any moment time when it is true, 
lnat is, for some predicate P, P = 3t[P(t)]. 

This section has two parts. It first discusses computation paths and net transi- 
tion graphs. It then gives the algorithms for generating timing constraints. 

4.5.1 Computation Paths and Net Transition Graphs 

Computation paths and net transition graphs are formal tools used by steady state 
behavior validation. A computation path is the list of nets, in order, that a node 
is a member of during a computation. Figure 4.3 shows two different computation 
paths for the S node of the Latched Inverter Cell (Figure 2.2). In the upper example 
S begins connected to Vdd. Then Latch, falls isolating S. In the lower example S 
begins isolated. Then Latch, goes high (while Input, is high) and then low, isolating 
b again. The labels of the edges indicate which signal causes the transition and its 
direction of change. For transistors that turn on, the label also includes a predicate 
describing the net that merges with the net undergoing the change. For example, 
the first edge of the lower path indicates not only that Latch, is asserted, but that 
it does so when In. is asserted. Had In. not been asserted, the resulting net would 
not have included Gnd. 

The possible computation paths of a given node are formalized as paths through 
a net transition graph. A node undergoes a net transition when the net it is a 
member of changes due to some transistor changing state. For example, referring 
again to Figure 4.3, the change from net [S] to net [Gnd Vdd Out S] is a net 
transition. The vertices of a net transition graph for node N correspond to the 
possible nets of N, and the edges correspond to net transitions of N. n The vertices 

11 To avoid ambiguity a net consists of nodes and conducting transistors whereas a graph consists of 
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Figure 4.5: The Net Transition Graph of the S node of Latched Inverter Cell. 



are labelled with the predicate selecting the net corresponding to the vertex. The 
edges are labeled as they are labelled in computation paths. A computation path 
is a traversal through a net transition graph. 

Each vertex in a net transition graph is annotated with the strength of the signal 
it corresponds to. A transition in the net transition graph from a vertex to a less 
strong vertex is called a downward transition, to a higher strength vertex is called an 
upward transition &nd to an equal strength vertex a sideways transition. Finally, 
two verges A and B are neighbors if there is some path of sideways transitions 
connecting them. 

For example, consider again the Latch Inverter Cell (Figure 2.2). The net be- 
navior equation of its S node is 

S„et = A t . Latch»(t) A In»(t) -► [S Vdd Out Gnd], 
Latch 4 (t) A N0T(In»(t)) - [S Vdd Outl, 
NOT(Latch»(t)) - [S] 

The net transition graph (Figure 4.5) for the S node of this cell has three vertices 
corresponding to S's three possible nets. Because each possible net can be trans- 
formed by a single transistor state change into one of the other possible nets, there 
are six edges m the graph. There are two downward edges for when Latch falls, and 
two corresponding upward edges, for when Latch rises. The are two sideways edges 
corresponding to In's two states. 

vertices and edges (also called ares). 
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Figure 4.6: Examples of the three ways a net can expand then contract. In the first 
diagram an upward transition is followed by a downward transition where both 
transitions are caused by the same transistor. In the second diagram an upward 
transition is followed by a downward transition where the two transitions are due 
to different transistors. In the third diagram an upward transition is followed by 
two sideways transitions, then a downward transition is made. 



4.5.2 Ensuring Strength Never Decreases After Increasing 

.■ tab J_*' af t#r const «ints ensure a signal's strength never decreases after increas- 
ing. When a signal's strength decreases after increasing the signal has undergone 
Momentary Expansion Corruption." Momentary expansion corruption is avoided 
by forbidding downward net transitions to follow upward net transitions. 

The ways a signal's strength increases and then decreases can be divided into 
three classes (Figure 4.6). The first occurs when a control signal (defined below) is 
asserted then unasserted (this is called a hazard). The second cause of momentary 
expansion corruption occurs when an upward transition is followed by a downward 
transition where the upward and downward transitions are caused by different sig- 

12 We are punning between corruption of nets and corruption of signals. We say N. is corrupted if 
and only if N is a dominant node of a corrupted net. 
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nals. The third cause of momentary expansion corruption occurs when an upward 
transition is followed by some number of sideways transitions then followed by a 
downward transition. 

All sources of momentary expansion corruption are avoided by the following 
requirement. ' ^> 

Rule 1: All signals causing downward transitions from a vertex V 
cannot change after any signal causing an upward transition into V or 
into a neighbor of V is asserted. 

hv f S . ta ^ 1 *" after i const u raints ' w hich ensure this rule is always met, are generated 
by the following algorithm. The algorithm is explained using the notation W 
which means The predicate P simplified under the assumption that A is asserted." 
For example assuming that b is asserted by making it true, (and a b c) lb reduces 
to (and a c), and b|b reduces to true. 

Algorithm Generate stable-after Constraints: 

Inputs: The net transition graph G of node N. 

Outputs: The stable-after constraints which ensure N. does not undergo Mo- 

mentary Expansion Corruption. 

Method: 

For each vertex V in G do 

Let P be the predicate choosing V. 
For each downward outgoing edge D from V do 
Let SD, be the signal causing D. 

For each upward edge U into V or into a neighbor of V do 
Let SU, be the signal causing U. 
Issue the timing constraint 
"P|SU» =► stable-after(SU„ SD,)." ■ 

For example consider again the Latched Inverter Cell (Figure 2.2), and the net 
ransition graph of its S node (Figure 4.5). The above algorithm generates the 
following two stable-after constraints on Latch: 

• In* -+ stable-after(Latch„ Latch,) 

• ^In» -► stable-af ter(Latch„ Latch,). 

These two constraints are collapsed into stable-after(Latch„ Latch,), which is 
then simplified to control (Latch,). A control signal is a signal that, once asserted, 
must remain asserted. ^^ ' 
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Figure 4.7: Voltage Changes. Under pessimistic enough conditions, asserting Cl 
can pull X low. 6 



4.5.3 Ensuring Strength Never Decreases After the Voltage 
Changes 

As mentioned above, Driven Corruption occurs when the initial strength of a signal 
is oo and the voltage of the signal changes before the strength of the signal becomes 
finite For example, considering the Latched Inverter (Figure 2.2) again, S. under- 
goes Driven Corruption when the computation path [S, Vdd, Out, Gnd] - fS, Vdd 
OutJ -. [S] occurs. In this computation path S» starts out at but goes to 1 before 
being isolated. 

Driven Corruption is avoided by requiring a signal's strength to decrease before 
the signal s voltage changes. Unfortunately, a completely strict enforcement of this 
wil make it impossible to verify many reasonable circuits. A strict interpretation 
of this rule will disallow driven nets to expand before contracting. For example 
Z S r?^ f atC rOUt ;* to A two Iatchcs ( Fi *«~ 4.7). Assume that Cl.fo) is unasserted 

f til 18 u "** Al8 ° aSSUme that Cl » and C2 » can chan *» during the same 
phase If C2» becomes unasserted before Cl» is asserted, no problems arise. If Cl> 

?h7™n g \ ' , v Ver i ^ n , Xt "■* 8uffcr a large volta « e chan « e Spending on 
the capacitance of Y and the driving force of the gate. 

Circuits such as this are common. We therefore ignore the effects of purely 
capacitive nodes and declare that voltage changes do not occur between comparable 

2 VC \ aa° n f f* Com P arable if and on* ^ they be transposed into each 
other by adding and subtracting undriven nodes from their periphery (Figure 4 8 
shows an example). We now state the rule that is used to prevent Driven Corruption. 

Rule 2: Signals causing downward net transitions from a driven 
vertex V must change before signals which cause sideways transitions 
to incomparable nets change. 

The following algorithm enforces Rule 2 by issuing falls-first constraints. 
Algorithm Generate falls-first Constraints: 
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Figure 4.8: Comparable and Incomparable Nets. Two driven nets are comparable 
if they can be transposed into each other by adding and subtracting undriven nodes 
at their periphery. The two nets in the first half of the figure are comparable The 
two nets in the bottom half are incomparable. 



Inputs: The net transition graph G of node N. 

Outputs: The falls-first constraints which prevent Driven Corruption of N, 
Method: 

For each vertex V in G do 
Let P be the predicate choosing V. 
If V corresponds to a driven net then 
For each downward outgoing edge D from V do 
Let SD, be the signal causing D. 

For each sideways edge U of out of V into an incomparable vertex 
Let SU, be the signal causing U. 
Issue the constraint "P A -SD»(*,) =► falls-first(SD„SU.).» ■ 

For example, consider again the Latched Inverter Cell's S node and its net 
transition graph (Figure 4.5). The above algorithm generates the following two 
falls-first constraints. 

• In» A Latch* A-iLatchjf*,) =► falls-first(Latch„ In,) 

• -In» A Latch 6 A-iLatch^/) =► falls-first(Latch„ In.) 
These two constraints are merged to yield 

Latch» A-.Latch»(t / ) =► falls-first(Latch„ In.). 



4.6. IMPLEMENTATION ISSUES 

ol 

The predicate is abbreviated f «ll.(Utch,) to yield the final form of the constraint: 
f all.(Latch») => falls-first(Latch., In.). This constraint prevents the voltage 
on S from changing before S is isolated. 

Figure 4.9 restates the restrictions and merges the two algorithms together. 

4.6 Implementation Issues 

There are two notes on the implementation that bear mentioning. First, Silica 
Pithecus does not perform a timing analysis. It therefore cannot determine the 
relative ordering of changes in signals. Second, the designer envisioned data depen- 
dencies between control signals are usually much coarser than the data dependencies 
embedded in constraints. This observation is exploited by trying to prove timing 

^TJTtv « nd * coaraer da ' a ^pendencies than under which they are pred- 

icated. This results in faster, simpler proofs. 

Silica Pithecus does not perform a timing analysis; it cannot prove that some 
signal changes before some other signal. Therefore Silica Pithecus cannot verify 
circuits relying on races. Silica Pithecus proves that Y. falls before X. changes 

f 'if " r Sa v c, f „ irSt constraints ) h y sh <™ing that X. is stable when Y. can 

fall. Likewise, Silica Pithecus proves that X, doesn't change after Y. rises (t e 
satisfies stable-after constraints) by showing that X. is stable when Y. can rise.' 

£ ■? J ?u g SyStem Iead8 t0 false ne * ativ <*- These false negatives can 

be avoided by incorporating a timing system into Silica Pithecus. However, since 
circuits which rely on races are rare, this is not a major drawback. 

The dependencies intended by the designer are simpler than the data dependen- 

^~T ag J? mtn i!* a ' u A dCSigner ° ften intends a "■Wrficm on a signal to hold 
under all conditions, but the timing constraints only restrict the signal under a few 
specialized conditions. For example, where timing constraints require a signal to be 
a control signal only at certain times, a designer often intends the signal to always 

.uilT K Slgna . , A SeC °, nd CXample iS a Signal Which constraint generation re- 

t'o be sUbU duringC "* *"*" C ° mPUtati ° n °> ^ *** the **"« intends 

Silica Pithecus exploits the simpler data dependencies of real designs by attempt- 

!h?n°r 7 ¥ COnstraints "*** ™Pl" (^ore restrictive) data dependencies 
than they are predicated under. This is advantageous because it is easier to sat^ 
isfy timing constraints using simpler data dependencies. For example, when Silica 
Pithecus has to prove that Y. is a control signal on J>, it first tries to show that Y. 
either is stable on P or that Y, is always a control signal. Only if these attempt 
fail does it try to prove Y. is a control signal on P. 

When proving some restriction is true on P Silica Pithecus will sometimes try 
to prove the restriction holds even when P is false. For example, often the only 
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Rule 1: All signals causing downward transitions from a vertex V cannot change 
after any s lg nal which causes an upward transition into V or into a neighbor 
of V is asserted. 

Rule 2: Signals causing downward net transitions from a driven vertex V must 
change before signals which cause sideways transitions to incomparable nets 
change. 

Algorithm GENERATE TIMING CONSTRAINTS: 

Inputs: The net transition graph G of node N. 

Method-' ThC C ° nStraintS Which ensure a si « nals stren 8 th do <* ^e right thing. 

For each vertex V in G do 
Let P be the predicate choosing V. 
For each downward outgoing edge D from V do 
Let SD, be the signal causing D. 
[Generate stable-after constraints.] 
For each upward edge U into V or into a neighbor of V do 
Let SU, be the signal causing U. 
Issue the constraint 
"P|SU» =► stable-after(SU„SD,)." 
[Generate falls-first constraints.] 
If V corresponds to a driven net then 
For each sideways edge U of out of V into an incomparable vertex 
Let SU, be the signal causing U. 
Issue the constraint 
"P A ^SD»(*,) ■=> falls-first(SD.,SU,)." ■ 

Figure 4.9: The Restrictions on Net Transitions and Their Implementation. 



4.7. A COMPLEX EXAMPLE 

Precharge J T~ 

' ^ Internal r<j f Out 

Tv 

Enable 



A:^ ^ UC 



i 



Figure 4.10: An OR Gate Implemented in CMOS Domino Logic. Node Internal is 
goe^ high ° n Enabk gOCS h!gh ° n *" A * ^ B# mUSt be Stable when EnabIe 



relevant term of P is that some clock is asserted. If the clock is asserted, then the 
restriction will hold regardless of whether P itself is true. 

4.7 A Complex Example 

As a more complex example consider an OR gate designed with CMOS Domino 

ST*! u , ] if lgUfe 4>10) - U i8 ^ M folIows - 0n one P^e Precharge is 
held high and enable, is held low. During this time A. and B. are free to settle. 
On the next phase Precharge, is low while Enable, is high. During this time A. 
and B are stable. The relationship between signals informally stated above are 
automatically discovered, and stated as timing constraints. 

4 i S n ° W u h ! ne V ransition « ra P h of the ^^l node of this device (Figure 

t U L Jf 1S fv P u VertiCeS ^ tWelve transitions - The timing constraints 
generated for this graph appear in Table 4.1. The numbers in this figure correspond 
to the numbered vertices in the OR gate's net transition graph. 

The timing constraints are summarized and compared against the designer's 
restrictions in Table 4.2. The only restrictions that match completely are the ones 
requiring Precharge to be a control signal. The other timing constraints depend on 
more factors than the designers restrictions. The designer intends A. and B. to be 
stable when Precharge, is low, they only change when Precharge, is asserted. The 
timing constraints only require A , and B. to be control signals when Precharge, 

"The graph in the figure is not the real graph, which has 11 vertices and approximately 40 arcs 
rather thT^ee ""'" ^ """^ Bod-i t0 *" "P re " nt «* * only one vertex 
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Figure 4.11: The Net Transition Graph of Internal Node of the CMOS Domino 
Logic Or Gate. This is an abbreviated form of the real net transition graph. In this 
graph vertices with same set of nodes are merged. 



4.8. GENERALIZING TO MULTIPLE TYPES OF TRANSISTORS 

1. NOT(A») A NOT(B») -+ control (Precharge,) 

2. A t V B t -♦ control(Precharge,) 

3. A t V B b -► control(Enable,) 

Enablej -+ control(A,) and control(B.) 
A» -► stable-after(Enable„ A.) 
B» -♦ stable-after(Enable„ B,) 
Enable* -* stable-after(A„Enable,) 
Enable» -+ stable-after(B„ Enable,) 

4. N0T(A») A NOT(Precharge t ) - controlfB.) 
N0T(B») A NOT(Precharge 4 ) - control(A.) 

Table 4.1: Timing Constraints for the Domino Logic OR Gate. 
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is low rather than to be stable. Also, where the designer intends Enable, to be a 
control signal, the timing constraints only force it to be a control signal when A 6 or 
Ok is nieh. 



4.8 Generalizing to Multiple Types of Transistors 

This section generalizes the ideas to include circuits containing multiple types of 
transistors The theory readily extends to transistors which conduct when their 

f 1 "\™ * ° VOlt8) SUCh M re**™ 1 transistors. (Silica Pithecus only 
handles nMOS circuits with only one type of positive threshold transistor.) 

The theory does not readily handle circuits containing transistors with different 

S« w* t , In , particular ' " *>«'t ^"ectly handle multiply connected 
nodes where the redundant transistors have different thresholds. Nodes X and Y 
are multiply connected when there is more than one path of conducting transistors 

redundant tranSiSt<>r8 ^ ^ ^ mdtiple Paths pOS8ib ' e are called 

uJ° T ^T^V f? n J sider r a cM0S transmission gate (Figure 4.12). This device is 
used as a threshold drop free switch [Weste]. When A, is asserted both transistors 
are conducting. If X is at Vdd, Y will eventually be pushed to Vdd across the p- 
channel transistor. If X is at Gnd, Y will eventually be pulled down to Gnd across 
the n-channel transistor. If both transistors are conducting (which occurs when 
A. changes vdue) there are two connections between X and Y. If either transistor 
stops conducting, X and Y will still be connected because the other transistor is 
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Generated Constraints 



control(PrechargeJ 



Enable & -> control(A,) " 

A t A B t A-.Precharge 4 -+ control(A.) 

stable-after(Enable„A.) 

atable-after(A„Enable,) 

Enable 6 -»• control (B.) " 

A t A B t A^Precharge 6 -> control(B,) 

stable-after(Enable„B,) 

atable-after(Enable„B,) 



Designer Restrictions 



Same 



iFrecharge t -+ stable(A.) 



A t V B b -f control (Enable,) 



■^Precharge 6 -► stable(B,) 



control(Enable,) 



Table 4.2: Comparing the Designer Restrictions and the Generated Restrictions. 



A l 



-T 

niftn i 1 ?;. C , M ° S Truu ^ m Gate ' Thi * » an example of a circuit which gives 
rise to multiply connected nodes. This circuit occurs frequently in practice. 



still on Therefore, there are three configurations of the transistor states yielding a 
net containing X and Y. 

As an example of circuit where multiply connected nodes cause problems, con- 
sider the circuit of Figure 4.13. In this figure there are two types of positive threshold 
ransistors The transistor gated by B is of one type and the other transistors are of 
the other type The transistor gated by B has a threshold (called Thresh-B) which 
is lower than threshold of the transistor gated by A (called Threah-A). Assume that 
all transistors are initially off and that N is at ground. If the circuit undergoes the 
transitions A high, B high, B low, my method will calculate the wrong voltage for 
N, namely VDD - Thresh-A. The correct voltage is VDD - Thresh-B. This bug 
arises because the original rules did not account for different threshold drops. 

The correction is to treat some sideways transitions as if they were upwards 
transitions. This is done by assigning to vertices secondary numbers based on the 
types of transistors m them. These secondary numbers can be used to order vertices 
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Figure 4.13: A Circuit Containing Two Types of Positive Threshold Transistors. 
All the transistors are n-channel. The threshold of the transistor gated by A is 
thresh-A and the threshold of the transistor gated by B is thresh-B. Thresh-B 
is smaller than thresh-A. 



just as strength is used to order vertices. Transistors with smaller thresholds would 
have higher secondary numbers associated with them. With this subnumbering 
scheme the original rules of computation paths can still be used. Vertices would 
first be ordered by strength and secondarily by types of transistors. 

4.9 Summary 

Signals are abstracted into digital values by first making sure they are valid, and 
then turning their final values into digital values. A signal N, is valid when N^ft,) 
is not corrupted. "«w/ 

An explicit representation for signal behavior, called net transitions graphs was 
developed. This representation makes invalid signals explicit. It also yielded a fast 
and effective method for automatically generating constraints which guarantee all 
output signals will be valid. 

The method was extended to handle all MOS processes. The extension only 
required a more precise ordering of the possible nets of a circuit. 
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Chapter 5 
Non-isolated Inputs 



This chapter confronts non-electrically isolated inputs. The Inverting Latch of 
Chapter 1 is an example of a circuit with a non-electrically isolated input. When 
Latch is asserted, the input node In is connected to node S. This connection af- 
fects the input signal applied to In. There are two ramifications of non-electrically 
isolated inputs. The first is ensuring information flows from an input node into a 
circuit, rather than vice versa. The second is augmenting the generation of timing 
constraints to accommodate nets which contain input nodes. 

Another type of constraint, called a flow constraint, is needed to ensure that 
input nodes act as inputs. An input node N of circuit C acts as an input only when 
the signal S applied to N is not materially changed by C. S is materially changed 
_by connection to a C when the abstraction of S when it is connected to C and the 
abstraction of S when it is not connected to C differ. When S is materially changed 
by C then N is acting as an output node. Input signals are usually materially 
changed by momentary connections to driven nodes and by charge sharing bugs 

This chapter has two sections. The first section discusses flow constraints. The 
second discusses issuing timing constraints for nets which contain input nodes. 

5.1 Flow Constraints 

Flow constraints dictate that signals must flow into input nodes and out of output 
nodes A node acts as input of circuit C only when signals flow into C circuit 
through it. Likewise, a node acts as an output of circuit C only when signals flow 
out of C through it. The generation of flow constraints requires access to a circuit's 
intended digital behavior. The intended digital behavior defines which nodes are 
inputs and which are outputs. 

For example, consider again the Inverting Latch of Chapter 1. Assume that the 
capacitance of its S node is lOOpf. Further assume that its Input node is connected 
to a precharged bus whose capacitance is only 50pf. When the Latch goes high 
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signal flow will be from S to Bus, thereby changing Bus. This change is contrary 
to the doner's intentions of Bus changing S. In this scenario, Input is act^g 2 
an output node, not as an input node. ^ 

sien^h^T 18 COnStrained by the overpowers constraint. There are two ways a 

TreatThan Y W """ST" V*"? ^ Yi when *' s st ^gth is sufficiently 
greater than Ys strength, 1 or when X and Y have the same logical value. The first 
coupon can be checked statically without recourse to the «rltime» behavior of 
a circuit. A signal X overpowers a signal Y when V* [overpowers (X.(t), Y.(t))l. 

tion T h rnew a T, Can , be T^ ""^ * ^g the Itraction fine 
chT^J K T ab8tractl °" function re J<"* input signals which were materially 
changed by the circuit to which they were input. We will not develop the formal J 
pecte of motivating flow constraints. The interested reader is encouraged to conduct 
this investigation on her own. conauct 

The following notation is used in this chapter. Let Net = {N U ..., N n ] be a net 
Net* represents the signal value computed by Net at node N<. 

5.1.1 Input Nodes 

wtif "*",,," ^ InPUt n ° de t0 drCuit C When the *** WKed to N by the 
eST ;TT" ^ SignaI appUed to N h * C - Let " b. the transistor 
Lt £ ™T "!? ^ ^ n ° de ° n the ° ther Side ° f the tran8ist <» fa« * . A node 

WOT ov" ^ n ' f ° r ^ timC *' the Mt ° n N '° 8ide of th « *«"■*« (called 

A2VF2) overpowers the net on O's side of the transistor (called ONET). Therefore a 

.flow constraint for input node N has the form P => overpowers^^ ONET ) 

where P is the predicate which causes ,VW to be onone side of I ^a'nd ONeI 

L het™ fN 6 wf 1 T ' Wh6n fl ° W C ° nStraintS are « enerated "^alwfys 
Wmes aTet constraints are propagated (ef. Chapter 11) NNET 

^ For example, consider the Inverting Latch again. Its In's net behavior equation 

Inn«t = A t . Latchi(t) -> [In S], 

NOT(Latch»(t)) -+ [In]. 

Latch» =► overpowers([In] /n , [S] s ) 

Wtm^atih f V 8 ^ th ! rd ^^^ ° f the fOUT COMtraints « enerated *>' ^e 
Inverting Latch.) In general, an input node having N clauses in its net behavior 

Silica Pithecu. define, "sufficiently greater- a. an order of magnitude greater. 
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expression will generate N - 1 flow constraints. The following algorithm generates 
now constraints for input nodes. 

Algorithm Generate Flow Constraints for an Input Node /• 

Inputs: J's net behavior NB. ^«u« *■ • 

Outputs: The flow constraints ensuring / acts as an input node 
Method: 

For each clause C of NB do 
Let Net be the consequent of C and P be the predicate of C. 
Let T be the transistor gating J. 
Let O be the node on the other side of T from J. 
Let ONET be the net on O's side of T. 
Issue the flow constraint U P =► overpowers([I] 7 , 0Net o )". ■ 



5.1.2 Output Nodes 

Node N acts as an output node of circuit C only when information flows out of 
C through N. This is the inverse of an input node. Using the same notation 
as tor flow constraints on input nodes, flow constraints on output nodes look like 
P =» overpowers(ONET , NNETjv). 

Output constraints are not explicit. When an output node connects with an 
input node, satisfying the flow constraints of the input node automatically satisfies 
the flow constraints of the output node. When two or more output nodes connect, 
Silica Pithecus checks for conflicts: when two different devices can simultaneously 
drive the same node to different values an error is signalled. 

5.1.3 Buses 

Besides input and output nodes, circuits also use bu* nodes. A bus node sometimes 
acts as an input node, and sometimes acts as an output node. The methods above 
do not work for bus nodes because they are not purely either input or output nodes. 
The solution is to examine the intended digital behavior to determine when a bus 
node is to act as an input and when it is to act an output. Flow constraints are 
tnen generated to make buses act appropriately. 

5.2 Timing Constraints 

When a net NET contains an input node special care must be taken to ensure the 
input node doesn t corrupt NET. If the input node changes value before being shed 
from NET then NET may be corrupted. Extra timing constraints (specifically, 
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falls-first constraints) must be generated to avoid this form of corruption. The 
following algorithm is used to generate these constraints. 

Algorithm Generate More falls-first Constraints: 

Inputs: The net transition graph G of node N. 

Outputs: The falls-first constraints which prevent Input Node Corruption of 

IN # . 

Method: 

For each vertex V in G do 
Let P be the predicate choosing V. 
If V contains an input node J then 
For each downward outgoing edge D from V to W do 
Let SD, be the signal causing D. 
If W does not contain J then 
Issue the constraint U P A -SD 6 (f / ) => falls-first(SD„I,)-" I 



Chapter 6 
Silica Pithecus 



Silica Pithecus is the implementation of my theory of multilevel verification of MOS 

S'S? ™ Pte I diSCUSSCS thC structure of Sili <* Pithecus and presents parts 
ot biuca Pithecus undeserving their own chapter. 

The major operations performed by Silica Pithecus depend on whether it is 
performing flat verification or hierarchical verification. The primary operations of 
Silica Pithecus when performing flat verification are constructing a representation 

IT 4 K r S at ^ inVaUd Signal8 apparent ' and issuin « constraints which 

ensure those invalid signals never arise. The primary operation of Silica Pithecus 

when performing hierarchical verification is processing constraints to show they 

ti«n C ^Ti^ l oth form f T the inputs to SiIica Pithecus ' namel y the s P eci nca- 

tion of digital behavior and the specification of circuit structure. Digital behavior is 
specified as a program written in a programming language supplied by Silica Pithe- 
tW rS ? g ^ e an . int fP reter » specifications can be debugged by executing 

vaZ £ I Cr v t^l m d \ tail the s P ecification ^digital systems and the moti" 
vation for Silica Pithecus's method of specifying digital behavior. The specification 
of circuit structure is not presented in this dissertation, but the representation of 
circuit structure is. 

This chapter has three sections. The first section discusses the structure of Silica 
Fithecus. The representation of circuits is presented in the second section. The last 
section describes how Silica Pithecus compares digital formulas. 

6.1 The structure of Silica Pithecus 

The structure of Silica Pithecus depends upon the type of verification it is perform- 
mg. We first discuss Silica Pithecus's operation during flat verification, then its 
operation during hierarchical verification. 
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Specification 
of circuit 
structure 




▼ 1 

Constraints Either CORRECT or INCORRECT. Here's why 



Figure 6.1: Outline of Silica Pithecus When Performing Flat Verification. 
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When performing flat verification Silica Pithecus has five phases (Figure 6 1) 
They are: '* 

Generation of net behavior. Net behavior, introduced in Chapter 2, is a rep- 
resentation of a circuit's dynamic structure. Net behavior makes explicit the 
tnmng constraints needed to ensure state is not corrupted. A hierarchical 
method is used to generate net behavior. Chapter 8 presents the details of 
generating net behavior. 

Issuance of timing and flow constraints. The algorithms for generating tim- 
ing and flow constraints were presented in Chapters 4 and 5. 

Generating and abstracting signal behavior. Silica Pithecus generates signal 
behavior from net behavior. Signal behavior is then abstracted to the digital 
level. During this phase threshold constraints are generated. 

Although generating signal behavior from net behavior is conceptually sepa- 
rate from abstracting digital behavior from signal behavior, the two are dis- 
cussed together. This is an artifact of intentional analysis; signal behavior 
itself ,s not important. The abstraction of signal behavior is. Therefore, 
much of signal behavior generation is bypassed, 1 which forces us to treat the 
two operations, generation and abstraction, together. Chapter 9 presents this 
part of Silica Pithecus. 

Checking the generated constraints. The generated constraints are processed. 
Rejected constraints are returned to the designer as errors. Propagated con- 
straints are attached to the circuit being verified. (At any given level of 
structural hierarchy a constraint is either satisfied, violated, or propagated to 
the next higher structural level.) 

Comparing arbitrary digital expressions. The comparison of digital expres- 
sions is a time-consuming operation. The general problem is NP-Complete. 
bilica Pithecus does not try to solve this problem elegantly. Instead, it relies 
on hierarchy to manage the problem. Silica Pithecus's comparison methods 
are presented m the third section of this chapter. 

The general theory of hierarchical verification is presented in Chapter 10. Chap- 
ter 10 shows the advantages of hierarchical verification, states the requirements on 
a verification system that make it work, and gives some concrete examples in the 
arithmetic domain. 

uree^r Perf ° rming hierarchical verification Silica Pithecus has four phases (Fig- 
1 Which is good, since generating actual signal behavior is very hardl 
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Figure 6.2: Outline of Silica Pithecus When Performing Hierarchical Verification. 



6.2. THE HIERARCHICAL REPRESENTATION OF CIRCUITS 
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PARTS 

*™J?0! Type Renaming Information 

MAD r at? ATE l raW,iSt0r ° rain S A ' Source S Gnd ' Gate » S ^rage 
wr1?e gItf r anstStor S rain s Bus ' Source * A ' Gate = Read 

WRITE-GATE Transistor Drain = Bus, Source = Storage, Gate = Write 

p m • CONNECTIONS 

Bus (Dram READ-GATE) (Source WRITE-GATE) 

A (Source READ-GATE) (Drain STORAGE-GATE) 

Storage (Gate STORAGE-GATE) (Drain WRITE-GATE) 

Unnamed (Source STORAGE-GATE) Gnd 

Table 6.1: Representation of the Three Transistor Ram 



Mapping components' constraints. The major part of hierarchical verification 
is the .mapping of the five different types of constraints. Each type of constraint 
has its own special handler. Chapter 11 discusses constraint mapping and 
constraint checking. * 

Checking the mapped constraints. This the same as for flat verification. 

Generating digital behavior. The digital behavior of the whole is the composi- 
tion of the components' digital behaviors. 

Structural comparison. The structural hierarchy of the derived digital behavior 
is compared against the funcational hierarchy of the intended behavior The 
comparison is described below. 

6.2 The Hierarchical Representation of Circuits 

Circuits are specified hierarchically where the primitive devices are those provided 
by the technology being verified (e.g., DFETs and EFETs in nMOS). My represen- 

S^XZpfi"* - PWI> tWS hiCrarChy - ThiS -P-ntation is nearly 

The primitive circuit element is the transistor. It has three terminals called 
Drain, Source, and Gate. Consider the Three Transistor Ram (Figure 8.2), which 
is composed solely of transistors. The representation of this circuit consists of a 
listing of its parts and the connections between them (Table 6.1). Circuit names 

(IT ^^wi^^T^ RAM) are written in italics ' and instance names 

(e.g., STORAGE-GATE) are hyphenated and capitalized. 

The structural representation of a circuit has two sections. The Connections 
section lists and names the connections between the components. The Parts sec- 
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tion lists the components, their names, and renaming information. The renaming 
information dictates how names of components map to names of the parent circuit 
Renaming information is used heavily. Note that the component's names (e.g., tran- 
sistor) are listed, not the components themselves. This is a "pointer" scheme by 
which only one prototype of a circuit exists regardless of how many larger circuits it 
is part of. There are two advantages to this scheme. The first is a saving in storage 
for circuits used many times. The second, and more important, is having to analyze 
a circuit once instead of the number of times it occurs in larger circuits. 

6.3 Comparison 

The type of comparison performed depends on whether flat or hierarchical verifica- 
tion is performed. Flat verification requires comparing arbitrary digital expressions 
tor equality. Arbitrary comparison is computationally intensive. Hierarchical ver- 
ification requires comparing structurally similar digital expressions. This type of 
comparison is computationally inexpensive. 

Silica Pithecus uses a very simple theorem prover to show two digital expressions 
are equivalent. The only complication is the presence of float's which occur in 
conditional expressions. 2 When faced with conditional expressions Cl and C2 Silica 
Pithecus shows that they are equivalent assuming that the first predicate of Cl is 
true and assuming that the first predicate is false. This generates two simpler 
subproblems. The second subproblem may involve conditional clauses, in which 
case the strategy is reapplied. 

When hierarchical verification is performed the structural hierarchy of the sche- 
matic and the functional hierarchy of the intended behavior must match. Silica 
Pithecus determines if the input/output relationships of the functions in the digital 
specification and the wires in the structure correspond (i.e., the procedures and 
components are similarly "wired"). 

For example, consider a sum of products device (Figure 6.3). Let the intended 
behavior of this device be 

(db (Sum-of -products x y z) 

( + (* x y) (♦ (* x z) (* y z)))) 

This device is correct only if devices PLUSl and PLUS2 were verified to have 
digital behavior '+», devices TIMESl, TIMES2, and TIMES3 were verified to have 
behavior and the are wire according to the dataflow prescribed by the intended 
behavior of the entire device. 



Don't can values would cause similar problems. 
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Chapter 7 

Specifying Digital Systems 

As defined in Chapter 3, the digital descriptive level consists of Booleans, float, 
boolean functions and join. All complex digital systems are created from These 
primitives This chapter addresses how we specify the combination of these primi- 
tives to build complex devices. 

wJ^ r^w 6 hard t0 deSCribe because there is no sin * le station that 

r C on^ r s t " {e - 9 r an f der ceii) ' medium (•■*' a ie bit ad ^). *» («.#.. 

a controller), and very large («.,., a whole chip) designs. Each level has Its own 
particular problems and nuances. Notations that work well for small designs are 
often too cumbersome for large designs and vice versa. The notation used by Silica 
Pithecus errs on the side of easily describing large designs at the expense of not 
concisely describing small designs. 

This chapter has five sections. The first section discusses the issues of describing 
digital behavior common to all designs regardless of size. The second section pro- 
poses using programs for specifying digital behavior^ and covers the advantages and 
disadvantages of doing so. The third section gives a rationalization and overview of 
the applicative programming language used by Silica Pithecus for describing digital 
systems. The fourth section is a reference manual of this language. The last section 
presents a large example which shows the specification of a reduced instruction set 
computer. 

To a large degree, there is nothing new in this chapter. Many of the ideas 
presented here are germane to the applicative programming community. Many 
of our arguments for using applicative programming languages in the description 
fori? ^r a Pf ear > n Johnson [Johnson] (though in a much less accessible 

form). Other researchers, [Sheeran, Johnson], use the same method of specification 
f^r™* M '<> Propose; the only difference is usually syntax. Nonetheless, 
for completeness, and for the edifi cation of readers unfamiliar with the applicative 
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approach, we now present a thorough discussion of the subject. 

7.1 Issues in Specifying Digital Behavior 

The major issues in specifying digital behavior are coverage, extent, and reliability. 
Coverage refers to specifying the behavior of a circuit for all its inputs and 
states. A specification that does not completely cover all inputs and states is called 
incomplete or partial. As will be discussed in more detail below, it is hard for 
specifications to exactly cover the intended digital behavior of a circuit: programs 
tend to over specify behavior, and logic tends to under specify behavior. 

Extent refers to the interval of time (measured in events, such as clock ticks 
not real time) used in the specification. For example, one may wish to specify that 
once asserted signal X. remains high until signal Y. goes low; this specification has 
greater extent than one time unit. 

Reliability measures the amount of faith one has that a specification is correct. 
As a basis for later comparison consider the luting method of specification: be- 
havior, ».«., next state and outputs, is specified by listing for each input and state 
of interest what the intended behavior is. (This method is, of course, infeasible due 
to the exponential number of entries required for even a modest circuit.) Assuming 
the listing was done correctly the coverage would be exact, there would be no spu- 
rious or lacking entries. It would have no extent. Its reliability could be checked by 
writing a simulator for the listing and running the listing as if it were a program. 

7.2 Specifying Digital Behavior with Programs 

Instead of listing all the entries one can write a program in a suitable language 
to compute the intended behavior. I define a "suitable language" as being small 
with well defined semantics. This section gives the advantages and disadvantages 
of specifying digital behavior with programs. 

7.2.1 Advantages of Using Programs 

Programs Can be Debugged and Verified 

Because a program can be executed and debugged, it can be very reliable. In com- 
parison to text editors and spreadsheets, the programs describing the digitial be- 
havior of even million transistor chips are rather small and extremely heavy testing 
of the program can occur. It is also possible to verify programs. Indeed, proving the 
functional correctness of digital designs is essentially the same problem as proving 
programs correct. 
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7.2. SPECIFYING DIGITAL BEHAVIOR WITH PROGRAMS 

Programs Allow Hierarchical Specifications 

An important property of programs is that they can be composed to make larger pro- 
grams. When functional programming languages are used functional composition 
alone suffices for composing programs. Programs therefore allow for hierarchical 
and modular specifications. The specification's hierarchy can be exploited to great 

•* J'JE? . Ve " fication if tt matches the structural hierarchy of the design being 
verified (this is discussed in Chapter 6). 

7.2.2 Disadvantages of Using Programs 

Programs are Poor at Specifying Asynchronous Systems 

Programs can be used to describe asynchronous systems. For example, CSP [ref- 
erence] and ADA tasks [Reference] can be used to models asynchrnous systems. 
Nonetheless, programs fail for specifying the intended behaviors of systems. The 
problem is that what we often wish to prove some property of the behavior holds. 
That after some time, the system will acknowledge a request, or that some ar- 

S rV^ f , arbit * tes ' Such Properties are best specified by temporal logics 
[Mishra/Clarke] rather than by programs. 

Programs Have Coverage Problems When Inputs are Not Restricted 

Programs are prone to have coverage problems, they often specify behavior that 
should be left unspecified (i.e., a value is specified where there should be a don't 
care). This bug is very hard to catch unless it is specifically tested for: normal 
tests of program will probably never exercise the code that is "buggy." Indeed the 
program may have all the functionality and work correctly for all correct inputs. 
But the circuit to be verified may assign different values to the don't cares. When 
verified against the program it would not pass because it did not do what the 
program did. 

A concrete example will make this clear. Consider a memory circuit for storing 
four bits. There is one bus, four read lines, and four write lines. The designer 
may intend for only one bit to be writeable at a time and design the circuit that 
way That is, the circuit will write invalid values if more than one write line is 
asserted. A program to specify the memory could be written and "debugged" with 
only one write line asserted at a time without the designer noticing the program 
allows simultaneous writes to more than one bit. Even though the circuit may be 
correct and the specification "debugged," the circuit cannot be verified against the 
program since the circuit does not allow more than one bit to be written whereas 
the program does. 

The real bug is that the verifier does not know the constraints on the input 
signals. If they are known, a verifier would not attempt to verify behaviors arising 
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from disallowed input configurations (e.g., more than one write line asserted at a 
time). Silica Pithecus, which uses programs as specifications, requires constraints on 
inputs to be explicitly declared. These constraints are used during the comparison 
of the abstracted and specified behaviors. 

T.3 Rationale for Silica Pithecus's Specification 
Language 

The specification language should have several attributes: 

• It should be a programming language with an interpreter. 

• It should support modular specifications. 

• It should have simple and precise semantics. 

• It should be able to express parallelism. 

satiJfyingThem diSCUS8e8 theSC g0ah and 8ummari ** <*e language resulting from 

7.3.1 The Goals of the Language 

It should be a programming language with an interpreter. 

One should be able to debug the specifications by running them. If the specifications 
are not correct then the design will not be. 

It should support modular specifications. 

Modularity is the mechanism used to contain complexity. Complex systems are 
built by composing together less complex systems. A specification language must 
support modularity by allowing specifications to be composed to make complex 
specifications For example, a specification for a control unit and a specification for 
an ALU should be composable using functional composition. If either specification 
must be changed m order for them to be composed, then the language does not 
support modular specifications. Under this restriction, languages such as Pascal 
could not be used as a specification language because of potential clashes between 
names of variables. 

This goal constrains the evaluation mechanism for the language. Consider again 
composing a controller and an ALU together. If they simultaneously transmit 
data to each other then they cannot be emulated by standard applicative order- 
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that would require evaluating one before the other preventing simultaneous com- 
munication Some form of lazy evaluation must be used to model simultaneous 
communication. 

It should have simple and precise semantics. 

Simple and precise semantics is required by the need to know what a program in 
the language means. If that is not easily known then comparing programs (i.e., the 
abstracted and specified digital behaviors of a circuit) is meaningless. 

It should be able to express parallelism. 

The ability to express parallelism is mandatory because a digital circuit may be 
computing many things simultaneously. 

7.3.2 Overview of the Resulting Language 

The language that resulted from these goals is a functional language whose data 
types include boo eans, floats (whose sole member is float), vectors (ordered col- 
lections of objects) streams (infinite lists of objects), and both simple and higher 

arguments * ******* **"" automaticaI1 y dela y th « evaluation of their 

All of the goals are met by virtue of the language being functional and having 

firs class function objects. A functional language does not specify the order of 

evaluation of its terms. It therefore supports expressing parallism. Functional 

angauges generally have simple and precise semantics, this one has so few data 

types it's simpler than most. 

The only problem with this approach is specifying the behavior of circuits con- 
taming state: side effected variables cannot be used to model changing state. There 
are two solutions to this problem. The first treats circuits as functions from inputs 
and states to outputs and new states. This solution is undesirable because of the no- 
tational overhead of explicitly recapturing and transmitting state in every function 

Itl .IT*? ° r T,™ °u bJeCt With State - The ""** treate circuitsTontaining 
state as functions taking the initial state of the circuit and returning a function 
that takes a stream of the circuit's inputs over time and returns a stream of the 
circuit s outputs over time. Using this convention, purely combinational circuits are 
specified as functions mapping streams of input to streams of output. We will use 
the second solution. 

Although there are primitive, in the language for creating laiy constructs U e lambdal th. 
more pe„ pi cuous descriptions of digital system, result whei lasses, is ^pUcUty prc^oy tt 
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By using streams, functional composition can be employed to compose specifica- 
tions of objects containing state. For example, assume that A, B, and C are single 
bit shift registers already initialized with state, and that they take two arguments, 
Tel-* • v B ° th arguments are strea ms of l's and O's. When a component 
°! . t'f I "responding components of Input is shifted in and the current 
state shifted out; otherwise the shifter maintains its current state. A three bit shift 
register (,.«., it takes three shift instructions for the input to reach the output) can 
be specified as ' 

(lambda (input shift) (A (B (C input shift) shift) shift)). 

7.4 The Digital Specification Language 

This section is a detailed description of the language used by Silica Pithecus. It 
is heavily modelled after Scheme [Abelson]. 3 It differs in that it lacks certain data 
types and features (no catch/throw or quoting mechanism), and it adds destructur- 
lng binding and new function defining forms. It uses lexical scoping and a mixture 
of lazy and applicative evaluation. We do not present a complete description of the 
language. Only a listing of the data types, the functions operating on those types, 
and the special functions* of the language are presented. Readers not interested in 
the details can safely skim this section and the next section. 

7.4.1 Data Types 

There are five data types: Booleans, Floats, Vectors, Streams, and Procedures. 

Booleans 

There are only two boolean values True and False. They are denoted 1 and 0, 
respectively. The standard boolean functions and, or, and not are primitive^ 
provided. And and or take an unlimited number of arguments. 

Floats 

There is only one floating value, float It is bound to the identifier float. The 
only function in the language which accepts float is join. Join takes an arbitrary 
number of arguments. Each argument must be either float, true, or false. If all the 
arguments are float the result is float; if all the non float values are true (false) the 
result is true (false). Float is used to model tri-state busses. 

3 Modulo syntax, my spectfeation method for circuit, with states i, very similiar to the treatment 
of objects with states in Section 3.4.4 of [AbelsonJ. 

4 This term corresponds to what others have called sptcial forma. 
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Vectors 

Vectors are a data aggregating mechanism. They act like Lisp's conses. The prim- 
itive vector, which has no elements, but is bound to the identifier *empty*. A 
vector of length N is created using the procedure vector-cons which accepts an 
object of any type and a vector of length N - 1, and returns a vector of length 
AT If z * (vector-cons a b) then (first z) is a and (rest z) is b. The function 
nth-vector accepts a vector and an integer. It returns the nth element of the vector 
where the counting is zero-based. The function new-vector accepts a vector, an 
integer, and an object. It creates a new vector whose elements match the original 
except for the nth one, which is the object. 8 The function vector takes an arbi- 
trary number of arguments and returns a vector containing the arguments. That is 
(vector abed) is the same as (vector-cons a (vector-cons b (vector-cons 
c (vector-cons d *empty*)))). Vector can be abbreviated v. 

#<n> v<m> denotes a function call that returns a vector whose contents, when 
interpreted as binary representation of a number, is m. <n>, which is optional and 
defaults to 8, is the length of the vector the function creates. For example, typing 
#3v4 is the same as typing (vector l). 8 B 

The function = when applied to vectors returns TRUE if the vectors have the 
same length and if the corresponding elements of the vectors have the same boolean 
values. 

Streams 

A stream is a mechanism for representing "infinite vectors." A stream is constructed 
with stream-cons which accepts two arguments. If z is (stream-cons a b) then 
(now z) is a and (future z) is b. Stream-cons is like vector-cons, however, the 
second argument, rather than being evaluated, is delay ed. When future is called 
to retrieve the second argument it is forced to yield a value. By this mechanism 
delayed expressions can make use of variables which are defined after stream-cons 
is called. Stream-cons can be abbreviated sc. 

The function stream-map is used to map a function across a stream. For 
example, let x be a stream of boolean values, (stream-map (lambda (y) (not 
y) ) x) returns a stream whose values are the logical negations of x's values. 

Procedures 

Procedures are first class objects created by lambda. For example, 
(lambda (x y z) 

s The implementation need not copy the whole vector a. long as it acts like it does. 
6 By my conventions the first bit in a vector is the low order bit. 
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(and x (or y z))) 

denotes the function that accepts three arguments and returns the logical-and of 
its first argument with the logical-or the other two arguments. 

Notes on Types 

There are no functions for determining the type of an object. 

7.4.2 Special Functions 

A special function is a function not all of whose arguments are evaluated before 
invoking the function. Two special functions, cons-stream and lambda, have 
already been introduced. There are four types of special functions: special functions 
for controlling the evaluation process, special functions for creating procedures, 
special functions for binding variables, and special functions for naming "top-level" 
objects The four types are exemplified by the special forms cond, lambda, let, 
and define, respectively. 

Evaluation of Control Special Functions 

There are three special functions for controlling evaluation: cond, if, and select. 

nr^^ Tfli ( ^ <PrediCate> <con8e <^> «*•>). First if evaluates its 
predicate If the predicate returns True then if evaluates its consequent. Otherwise 
if evaluates its else clause. 

Cond is a generalization of if. Its syntax is (cond (<pl> <cl>) (< p2 > 
<c2>) (< pn > <cn>)). It evaluates the p's in turn. When one returns True 
cond evaluates its associated consequent. If any predicate returns a non-boolean 
value or no predicate returns True an error is signaled. 

The syntax of select is 

(select <selector> 
(<cl> <expl>) 
(<c2> <exp2>) 

• * * 

(<cn> <expn>)) 

This is the same as writing 

(cond ((■ <selector> <cl>) <expl>) 
((» <selector> <c2>) <exp2>) 

• • • 

((» <selector> <cn>) <expn>)). 
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Procedure Creating Special Functions 

The only special function for creating procedures is lambda. Its syntax is 

(lambda «argl> <argn>) <exp>) 

This create a procedure of n arguments whose body is <exp>. AH variables are 
lexically scoped. 

Variable Binding Special Functions 

There are two special functions for binding forms: let and rlet. The syntax of let 
is 

(let ((<namel> <expl>) 
(<name2> <exp2>) 

(<namen> <expn>)) 
<body>) . 

Let evaluate^ all the exps and then binds them to the names and then evaluates 
<Dody>. Names are either a sequence of characters, as in X, Y, and this-is-a- 
yariable-name, or a list of character sequences enclosed in parenthesis such as (A 
ttus-is-name C). In the latter case, the associated expression must return a vector 
the same length as the list. Each name in the list is bound to the corresponding 
element of the vector. This is called destructuring binding. Destructuring binding is 
used to work around the restriction that procedures only return one value. Examples 
are provided below. ^ 

Rlet stands for Recursive Let. It is like let except that the expressions of the 
rlet can refer to the variables being bound by the rlet and the evaluation of the ex- 
pressions are delayed until they are used. This allows simultaneous communication 
between components of a specification. 7 

For example, assume that Datapath and Controller are procedures repre- 
senting their namesakes. Assume further that each takes two inputs, one from 
the outside world and one from the other device, and that they each produce two 
outputs. They would be connected together as follows: 

(rlet (((controller-to-datapath-wire controller-output) 

(controller controllers-input datapath-to-controller-wire)) 
( (datapath-to-controller-wire datapath-output) 
(datapath datapath- input controller-to-datapath-wire)) 
(vector controlle r-output datapath-output))) 

7anl?^ e L th "l. meCha ^f • int<raCt ' P ° OTly With de »*™'«ria8 btadtag. Pathological circuit, 
can be specified whose speeding program, won't run due to definitional loop.. To get around 
this problem, the language must really be completely call-by-need. 
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The output of this expression is a vector containing the outputs of the controller and 
datapath which are destined for the outside world. This example uses destructuring 
binding to get at the two outputs of each subdevice (which each return a vector of 
their two output). A more concrete and fleshed out example is presented below. 

Special Functions for Naming Objects 

Define is used for naming objects at "top-level." The syntax is (define <name> 
<exp>). For example, (define x 3) associates X with the value 3. Similarly 
(define foo (lambda (x y) (+ x x y y))) associates the procedure created by 
lambda with the name foo. 

There are many syntactic sugarings for naming functions. These syntactic sug- 
anngs are motivated by the desire to make functions which operate on streams easy 
to write. 

Df (for Define Function) creates a procedure and associates the procedure with 
a variable. The syntax is 

(df (<name> <var-li»t>) <body>) . 
This is the same as 

(define <name> 

(lambda (<var-list>) 
<body>)). 

Db (for Define Behavior) is used for specifying the behavior of circuits without 
state. It lets one write a function apparently over scalars {i.e., non streams) but 
which operates over streams. For example, whereas the function defined by 

(df (xor a b) 

(and (or a b) (not (and a b)))) 

takes scalars, 

(db (Xor a b) 
(and (or a b) (not (and a b)))) 

defines a function taking and returning streams. Assuming only one argument (db 
(<name> <arg>) <body>) is the same as 

(define <name> 

(lambda (<arg>) 

(stream-map (lambda (<arg>) <body>) <arg>))) 
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The equivalences for functions having more than one argument are extrapolated 
from this one I use the typographic convention of capitalizing names of functions 

slreamsT^ ** *° ^^^ {< " WUch *** VeCt ° ra ° f Streams to vectors of 

Li J5t be ^ vio 7 f circ r uits w "h «tate is specified using a syntactic variant of df. 
Like db, it transforms functions taking scalars into functions taking streams. For 
example, consider a shift register which has one bit of state. It continuously reads 
a value and outputs the previous value read. It is specified 

(df ((SHIFTER state) input) 

(stream-cons state (shifter input))). 

This binds shifter to a function taking an initial value and returning a function 
that maps a stream into a stream. Using plain df this would be specified as 

(df (SHIFTER state) 
(lambda (input) 
(streaa-cons 
state 

((shifter (now input)) (future input))))). 

This is a simple example. For a more detailed circuit, such as a register with 
many inputs, the overhead of continually writing, for example, (now inputl) and 
(future input2 , is very large. I use the typographic convention of writing names of 
functions which take state information and then return a function mapping streams 
to streams (or vectors of streams to vectors of streams) in uppercase. 
Assuming one argument, 

(df ((<name> <state>) <input>) 
<body>) 

is the same as 

(define <name> 
(lambda (<state>) 
(lambda (<input>) 
(map-function-stream 

(lambda (<input>) <body>) 
input)))) 

where map-function-stream is 

(df (map-function-stream f unction-making-a-atreaa input-stream) 
(let ((stream 

(function-making-a-stream (now input-stream)))) 
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(stream-cons 
(now stream) 
(map-function-stream 

((future stream) (future input-stream)))))) 

7.5 Examples 

ImiSffi thC dlgita ! behaVi ° r ° f a Fanatica «y Haducad Instruction Set Computer 
(* RISC) . A picture of the machine and its architecture appears in Figure 7.1. The 
computer has the same interface and instructions as Gordon's example computer 
[Gordon83 ] but is implemented as a RISC machine (i.e., every instruction executes 
in one cycle) rather than as a microcoded machine. I also specify its behavior 
in much more detail. For example, Gordon treats the ALU and memory of his 
computer as primitive, whereas I fully specify the them. The difference in detail 
is due to his concern for verifying the functional behavior of the computer (i.e 
prove its microcode is correct), whereas I wish to verify the digital behavior of the 
computer. 

To the user the machine has a 13 bit Program Counter (PC), a 16 bit accumu- 
lator, a 2 word memory where a word is 16 bits wide, and 8 instructions. The 
instructions are 

HALT: Stop executing the program. 
JMP address: Set PC to address. 

JZRO address: If the contents of the accumulator is zero then the PC is set to 
address. 

ADD address: Increment Accumulator by the contents of address. 
SUB address: Decrement Accumulator by the contents of address. 
LD address: Load Accumulator with the contents of address. 
ST address: Store Accumulator into address. 
NOP: Do nothing. 



"This title is due to Jeff Siskind [SiskindJ. 

9 Barrow also uses Gordon's example computer in Verify (Barrow). Everything I say about Gordon's 
example computer apply to Barrow's example computer. 
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Figure 7.1: A Fanatically Reduced Instruction Set Computer. This computer has 
8 instructs each of which takes one cycle to execute. Its word size is 16 bits and 
its address space is 13 bits. 
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The computer's front panel contains a bank of 16 toggle switches, lights dis- 
playing the contents of the PC and the Accumulator, an idle light displaying the 
computer's state, a four position knob, and a button. If the machine is running 
pushing the button causes it to stop running. The knob determines what happens 
when the button is pushed when the machine is idle as follows: 

The PC is loaded from the toggle switches. 

1 The Accumulator is loaded from the toggle switches. 

2 The memory location specified by the switches is loaded from the accumulator. 

3 The program starts running from the location in PC. 

I will specify the computer in four steps. Each step illustrates a different aspect 
(and idiom) of specifying digital designs. The first step specifies cells. It emphasizes 
that a device's inputs and outputs are streams, not single boolean values. The 
second step groups cells together. It highlights the creation of vectors and the 
operations on vectors. The utility of using recursive functions to create arbitrarily 
sized devices is also discussed. The third step specifes the controller and datapath. 
It shows how large complex devices containing many disparate parts are wired 
together. Finally, the entire computer is specified. This is specification is amazingly 
small (as the reader can verify by peeking ahead to the end of this section). 

7.5.1 Small Cells 

I will show the specification of a combinational circuit (an adder cell) and a circuit 
containing state (a register cell). 

The Adder Cell 

A full adder takes three inputs and produces two outputs (Figure 7.2). The speci- 
fication of this circuit uses a helper function called xor. 

(df (xor a b) 

(and (or a b) (not (and a b)))) 

(db (Adder-cell a b c) 
(vector (xor a (xor b c)) 

(or (and a b) (and a c) (and b c)))) 

Because db was used to define the adder, its inputs and outputs are streams. 
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Figure 7 2: A Full Adder. This is a pictorial representation of the digital behavioral 
specification of an adder. This is not the MOS implementation. 
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Figure 7.3: A Register Cell. On * it is fed with data which is either fed back from 
its output or fed from an external source. On & the data is passed to the output 
gate. 



The Register Cell 

The register cell operates in two phases. On the first phase it is loaded with data. 
This data can either be fed back from its output or be external. On the second 
phase the data is passed from the "input port" to the "output port." Figure 7.3 
shows the nMOS implementation of this cell. Below is the digital specification of 
tne cell. 



(df ((REGISTER-CELL statel atate2) feedback refresh write input) 
(stream-cons 

; .* thia is the output . 

(if refresh atatel (not state2)) 

;: thia the next behavior of the device. 

(REGISTER-CELL (cond (write input) 
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(feedback (not state2))) 
(cond (refresh (not statel)) 
(1 state2))))) 

FRISC's PC has four input sources: feedback from itself, data from the memory, 
data from the instruction register (this implements jumps), and data from the 
mcrementer. The register cell for the PC is specified as 

(df ((PC-REGISTER-CELL statel state2) 

feedback? refresh from-ir? ir-input 

froa-aeaory? aeaory-input froa-inc? inc-input) 
(streaa-cons 

(if refresh statel (not state2)) 

(PC-REGISTER-CELL (cond (froa-ir? ir-input) 

(froa-aeaory? aeaory-input) 

(froa-inc? inc-input) 

(feedback? (not state2))) 
(cond (refresh (not statel)) 

(1 state2))))) 

7.5.2 Medium Circuits: Building Vectors of Cells 

F Z^t mCd i Um "S? e] T PU " ^ ^^ Which add8 tWO Similar len 8^ TOtor. 
together, and an arbitrary length register array will be specified. These circuits are 

specified as vectors of the appropriate cells. Because recursive functions are used 

in the specification, creating arbitrarily sized devices is automatic. 

An N bit adder 

LVcJL 3 ^ ple , VeCt r f " bC USed t0 rCpreSent UMi « Md inte « ere - G ™ two equal 
ength vectors (numbers) it produces their W The zeroth element of a vector 
is the low order bit. The input vectors contain streams of booleans and the output 
of the adder is a vector containing streams of booleans. 

(df (+ x y) 

(Adder-internal x y streaa-of-Os)) 

(df (Adder- internal x y carryin) 

(cond ((and (eapty- vector? x) (eapty-vector? y)) 
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♦empty*) 
((or (empty- vector? x) (empty-vector? y) 

(error "ran out of one vector")) 
;: the following let destructives the adder-cell's output 
(1 (let (((sum carryout) 

(Adder-cell (first x) (first y) carryin))) 
(vector-cons 
sum 

(adder-internal (rest x) (rest y) carryout))))))) 



An N Bit Register 

CRF ATF v m™^™if W ° rkS f ° r arbitrary length in P uts « The f ^tion 
i ^ 3^ ; BIT " REGISTER is Called with two vectors VI ^d V2 each of 
length N It then creates a register N bits long whose state is initialized to the 
contents of Vl and V2. The inputs to the register array are streams (for the control 
lines) and vectors of streams (for the word to be stored). Its output is a vector of 
streams. 

(df (CREATE-N-BIT-REGISTER vl v2) 

(let ((N-bit-register (CREATE- VECTOR-OF-REGISTER-CELLS vl v2))) 
(laabda (feedback refresh write Input) 
(Operate -on-n-bit-register 
N-bit-register feedback refresh write input)))) 

(df (CREATE-VECTOR-OF-REGISTER-CELLS vl v2) 
(if (empty- vector? vl) 
♦empty* 
(vector-cons 

(REGISTER-CELL (first vl) (first v2)) 
(CREATE-VECTOR-OF-REGISTER-CELLS (rest vl) (rest v2))))) 

(df (Operate-on-n-bit-register Reg feedback refresh write Input) 
(cond ((and (empty-vector? Reg) (empty-vector? Input)) 
♦empty*) 

((or (empty-vector? Reg) (empty-vector? Input)) 
(error "ran out of a vector.")) 
(1 (vector-cons 

((first Reg) feedback refresh write (first Input)) 
(Operate-on-n-bit-register 
(rest Reg) feedback refresh write (rest Input)))))) 



118 



CHAPTER 7. SPECIFYING DIGITAL SYSTEMS 



7.5.3 Large Circuits: the Controller and Datapath 
The Controller 

The controller has five inputs. Two of them, the knob, which determines what 
happens when the button is pushed, and the button, come from the front panel 
of the computer. Two, the opcode of the instruction being executed, and a signal 
asserting whether the contents of the accumulator is zero, come from the datapath. 
The last input is fa which is supplied by a fa generator living in the computer. 

The controller has two outputs, a wire going to the idle light and a group of 
control signals going to the datapath. I will first give the constants used by the 
controller and then specify the controller. 

; ; these are the control signals 

(define pc<-switches (v 0001000000010)) 
(define acc<-switches (v 001 000000000 1)) 
(define memory<-acc -no-fetch (v 0010010100010)) 
(define fetch (v 0010101000010)) 
(define nop (v 0010000000010)) 
(define pc<-ir (▼ 1000000000010)) 
(define pc<-pc+l (v 0100000000010)) 
(define acc<-acc+aea (v 010000001000 0)) 
(define acc<-acc-aem (v 010000000100 0)) 
(define acc<-memory (v 010000000010 0)) 
(define aemory-C-acc -fetch (v 0100010100010)) 
(define all-signals-low (v 000000000000 0)) 

; ; these are the opcodes 

(define halt #3v0) 
(define jap #3vl) 
(define jzro #3v2) 
(define add #3v3) 
(define sub *3v4) 
(define Id *3v6) 
(define st #3v6) 
(define nop #3v7) 

; these are the states 

(define idle #2v0) 
(define fetch #2vl) 
(define execute #2v2) 
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The computer can either be idling, fetching an instruction, or executing an 
instruction. Even when the computer is idling the controller is busy sampling the 
button on every cycle. If the computer is idle and the knob is in position 3 the 
computer will start running its program. If the computer is running then pressing 
the button will stop it." The select operation is used to decode the state of the 
controller and the opcodes it receives from the data path. 



(df ((CONTROLLER state) knob button -0? opcode phil) 
(if phil y 

(select state 
(idle 

(if button 

(select knob 

(#2v0 (sc (v pc<-switches 1) (CONTROLLER idle))) 
(#2vl (sc (v acc<-switches 1) (CONTROLLER idle))) 
(#2v2 (sc (v memory<-acc -no-fetch 1) (CONTROLLER idle))) 
(#2v3 (sc (v fetch 0) (CONTROLLER execute)))) 
(sc (v nop 1) (CONTROLLER idle)))) 
(fetch 

(if button 

(sc (v nop 1) (CONTROLLER idle))) .halt 
(sc (v fetch 0) (CONTROLLER execute))) ;run 
(execute 

(select opcode 

(halt (sc (v nop 1) (CONTROLLER idle))) 
(jmp (sc (v pc<-ir 0) (CONTROLLER fetch))) 
(jzro (if -0? 

(sc (v pc<-ir 0) (CONTROLLER fetch)) 
(sc (v pc<-pc*l 0) (CONTROLLER fetch)))) 
(add (sc (v acc<-acc+mem 0) (CONTROLLER fetch))) 
(sub (sc (v acc<-acc-mem 0) (CONTROLLER fetch))) 
(Id (sc (v acc<-memory 0) (CONTROLLER fetch))) 
(st (sc (v memory<-acc-fetch 0) (CONTROLLER fetch)) 
(nop (sc (v nop 0) (CONTROLLER fetch))))))) 
(sc (r all-signals-low (- state idle)) (CONTROLLER state)))) 



"The button must be constructed to only give a single pulse on the first cycle it is held down 
Otherwise the computer will thrash between the run and idle states. 
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The Datapath 

The datapath contains 3 registers (PC, ACC, and IR), three arithmetic units (an 
ontt'; nrr? >n«ementer), a boolean tester (which returns True if the 
output of ACC ,s 0), and a 8K word memory of 16 bit wide words. The functions 
specifying the registers are similar to the function specifying the register array 
presented earher m this section. The specification of the subtracter, incremented 
and boolean tester are similar to the specification of the adder. Only the memory 
unit is different, but its specification will not be presented here 

There are four outputs from the datapath. Two of them, the opcode of the 
instruction to be executed, and the zero test of the accumulator, are destined for 
the controller. The other two, the contents of the Program Counter and the Accu- 
mulator, are sent to the lights on the front panel. 

(df (DATAPATH ir pc ace mem) 

(let (Unstruction-reg (CREATE- INSTRUCTION-REGISTER ir)) 
(Program-counter (CREATE-PC-REGISTER pc)) 
(Accumlator (CREATE- ACCUMULATOR- REGISTER ace)) 
(Memory (CREATE-MEMORY mem)) 
(lambda (control-lines phil phi2 switches) 
(let (((pc<-ir pc<-pc+l pc<-pc pc<-sw 
ir<-mem 

mem.mar<-ir mar<-pc 
mem.data<-acc 

acc+ ace- acc<-mem acc<-acc acc<-sw) 
control-lines)) 
(rlet ((pc-output (Program-counter 

pc<-pc phi2 

pc<-ir (low-13 ir-output) 
pc<-pc+l (inc pc-output) 
pc<-sw (low-13 switches))) 
(ir-output (Instruction-reg 

phi2 ir<-mem memory-output)) 
(acc-output (Accumulator 

acc<-acc phi2 

see* (+ acc-output memory-output) 
ace- (- ace-output memory-output) 
acc<-mem memory-output 
acc<-sw switches)) 
(memory-output (Memory 

phil phi2 

mem.mar<-ir (low-13 ir-output) 

mem.mar<-pc output -pc 
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mem.data<-acc acc-output))) 
(vector acc-output 

pc -output 

(Vector-O? acc-output) 

(top-3 ir-output) )))))) 

7.5.4 Specifying the Complete Computer 

t WITH* 6 T PUt6r ^ n ° W be Spedfied by hookin « to * ether the datapath and 
the controHer. The output of the computer is the contents of the accumulator, the 
contents of the program counter, and the signal to the idle light. 

(df (COMPUTER state ir pc ace) 

(let ((The-controller (CONTROLLER state)) 
(The-datapath (DATAPATH ir pc ace))) 
(lambda (switches knob button phil phi2) 
(rlet (((control-lines idle-light) 

(The-controller knob button acc-0 opcode phil)) 
((acc-output pc-output acc»0 opcode) 
(The-datapath control-lines phil phi2 switches))) 
(vector acc-output pc-output idle-light))))) 

7.6 Summary 

In this chapter we discussed the specification of digital systems. The broader issues 
wI r C !' ng /t »**«»*■• first discussed then an actual descriptive system 
was proposed. We proposed using an applicative langauge for specifying digital 

an a^i. TT * "^ °" *"*"* for a ^language. We showed how 
an applicative language is a natural way for describing complex devices which are 

co moo s 7t 7 Pl « deViCeS ' * " a " natUral Way " b€CUase the datafl - » *£*£ 
composition directly mirrors the connections between physical devices That is 

dev.es specified by procedures are "wired up- by the ^ILn^t^i 
d T e^^u P aZ ble " * *"*»* *~» ** "™*" ^ *** - 
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Chapter 8 

Generating Net Behavior 

Net behavior, introduced in Chapter 2, was employed in Chapters 4 and 5 to gener- 
ate tuning constraints. In this chapter we discuss some of the philosophical under- 
pinnings of net behavior and show how it is generated. The philosophical under- 
pinnings relate net behavior to simulation and compilation. The generation of net 
behavior stresses concrete algorithms and the use of logical constants in eliminating 
non-existent nets. * 

8.1 Net behavior, simulation, and compilation. 

Simulators do a lot of work. Most of the work is repetitive reanalysis of the same 
nets over and over again. The problem is that a simulator must determine the new 
net partitioning that results from any change in transistor state. When the same 
transitions occur repeatedly (e.g., every time * goes high), the simulator must 
repeatedly determine the «new» partitioning. This "new" partitioning is usually 
the same as some previous partitioning. Even when a high-level control strategy 
is used, hke Mossim's Unit Delay, in which many transistors change state between 
partitioning, work is continually being replicated. 

An analogy can be made between a circuit simulator and a language interpreter 
A language has a semantics which is implemented by an interpreter, a circuit has 
a semantics which is implemented by a simulator. Just as an APL interpreter 
interprets APL programs, a simulator interprets circuits. Circuit simulators and 
language interpreters suffer the same problem: every time a language construct is 
interpreted, or transistors change state, a constant amount of the same overhead is 
repeatedly incurred deciding what must be done. 

Compilers are used to solve the problem of repeated overhead by incorporating 
the decision of what to do next within the program text. Sometimes this necessitates 
changing the program text (called a source level transformation), at other times 
it necessitates representing the program at a level closer to the interpreter (such 
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as translating source code into machine code the interpreter is written in) By 
incorporating the decision of what to do next into the program itself, the decision 
need only be made once at compile time. 

Net behavior only enumerates a node's possible nets once. Net behavior can be 
considered as a compiled form of a MOS circuit. The determination of the circuit 
partitioning for any given state of the transistors in the circuit is done once at 
analysis (compile) time. A major advantage of this approach is that it is possible to 
analyze each possible net of a circuit fully. Steady-state voltages can be determined 
for each possible net (assuming reasonable assumptions about the initial values of 
nodes are made). The goal of research in simulators is to find new ways of avoiding 
the^ analysis of a net and still accurately predict the steady-state voltages of the 
net s nodes. For example, this was the major motivation behind Mossim and its 
switch level, order of magnitude, circuit model. Mossim repeatedly rediscovers the 
same nets and can't spend the time to fully analyze each newly activated net When 
nets are only analyzed once, better models can be used. 

8.2 Generating Net Behavior 

A simple method is used to generate a circuit's behavior equations. The primitives 
(».«., transistors) have fixed net behavior equations. A nonprimitive circuit's net 
behavior equations are generated by composing the net behavior equations of the 
circuit s parts. This is standard practice in the field of behavioral analysis [Bobrowl. 
There are several advantages to this approach. 

• It exploits structural hierarchy. A circuit is only analyzed once regardless of 
the number of times it is used. 

• It is an incremental method. The work is spread over time as parts are 
connected instead of being done monolithically. As a result of, Silica Pithecus 
responses quickly. 

• It localizes the use of knowledge of a circuit's logical structure. Logically 
disallowed nets are pruned quickly, avoiding exponential blowup. Other, non- 
hierarchical methods, such as path tracing, are hard to manage because of the 
nonlocalized (and therefore inefficient) use of logical constraints. 

Net behavior equations are only created for state nodes and nodes gating tran- 
sistors. They are not created for connection nodes. For example, consider the 
standard nMOS NAND gate (Figure 8.1). The initial voltage of node X in Fig- 
ure 8.1 cannot affect the value of the output node. (Although it does affect the 
timing of the transitions of the output node.) Connection nodes are only partially 
analyzed by Silica Pithecus. 
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Figure 8 1: An nMOS NAND Gate. The state of internal node X does not contribute 
to final state of of the output the gate. X therefore does not store state and is not 
fully analyzed. 



Silica Pithecus uses a different control strategy for generating net behavior than 
the one described here. The one described here is clean and easy to explain. For 
pragmatic reasons, the control strategy employed by Silica Pithecus is more com- 
plex. Interested readers can look at the code. 

Behavior generation for a circuit C is done in three steps. The input to behavior 
generation is the behavior equations of C's parts. The output is the behavior 
equations for C. The three steps are: 

1. Renaming the behaviors of the subcircuits of C which use names local to those 
subcircuits to use names of the circuit C. 

2. Merging nets where subnodes connect. Merging is done for all nodes. 



3. 



Expanding nets to span the circuit C. Expansion is the most expensive part 
of net behavior generation. It not performed for connection nodes. 

This section has three parts corresponding to the three steps above. As a running 
example I will show how the behavior equations of the Three Transistor Ram (Figure 
8.2) are generated. This device stores one bit on its Storage node. It is composed 
of three transistors, Read-Gate, Write-Gate, and Storage-Gate, and six nodes, Bus, 
Read, Write, Storage, A, and Gnd. The Bus node, after being connected to many 
other cells, will have a larger capacitance than the Storage or A nodes; Read and 
t. pm mU S y "d"*™- The net behavior of this device appears in Figure 8.2. 
me KAM cell has a temporal logical constraint of tautex(Read„ Write.). This 
constraint is employed during steps 2 and 3. 
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Bus(Large Capacitance) 



Write 



? 



Read-Gate] ( — 



Storage 



Read 



Write-Gate Storage-Gate 

Figure 8.2: Schematic of 3 Transistor Dynamic Ram. Bus, A, Storage, Write, and 
Read are nodes. Read-Gate, Write-Gate, and Storage-Gate the RAM's parts. Read* 
and Wnte» are not simultaneously asserted. 



8.2.1 Renaming Behaviors 

The net behaviors of a node's subnodes 1 must be renamed to the structural level 

of the circuit whose net behavior is being generated. A net behavior equation is 

renamed by changing names local to the circuit's subcircuits to names used by the 

circuit. The following algorithm is used to effect this: 

Algorithm RENAME: 

Inputs: A subcircuit C, its net behavior equations E, and its renaming table R. 

Outputs: New behavior equations based on E where names have been changed to 

reter to names used by C's parent. 

Method: Replace each name N in E with its associated name in R. I 

For example, in the Three Transistor Ram, the Source, Drain, and Gate nodes of 
its three transistors must be renamed to its Bus, Write, Storage, Read, A, and Gnd 
nodes. The relationship between the names local to the Three Transistor RAM's 
parts and its own local names is shown in Figure 8.3. 

m oT id £ again the behavior equations of the nMOS n-channel transistor (Ta- 
ble 2.1) They use names local to the transistor. Renaming the behavior of the 
Read-gate, for example, yields equations identical to those for the nMOS transistor 
except for the names used: 

Bus*,, = A t . Read t (t) =► [Bus A], 
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Figure 8.3: Renaming the transistors of the Three Transistor RAM. 



A-net 

Read^t 



= At 



= At 



N0T(Read»(t)) =► [Bus] 
Read»(t) => [Bus A], 
N0T(Read»(t)) =► [A] 
[Read] 



The two other transistors are similarly renamed. 

8.2.2 Merging Nets 

When subnodes connect their possible nets must be merged together. The function 
Merge is used to merge nets. Let N and M be nets with edges N.^, and M tdat 
and nodes JV^*. and M^., respectively. Then (Merge N M) = O where O ti ,„ = 
Me*,,. U M tdgt , and O^ = Nnj.. u M^.. Merge can be extended to expect an 
arbitrary number of arguments. 

Behavior expressions are merged together using the following algorithm: 
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Algorithm MERGE NET EXPRESSIONS: 

Inputs: A node and the net behavior expressions of its subnodes. There is one 
expression per subnode. 

Outputs: An approximation to the net behavior expression of the node. 
Method: Apply the function Merge to the node's subnodes' net expressions. Then 
rewrite the resulting expression into standard form. An expression is in standard 
form when 1) the top level expression is a conditional, 2) all its predicates consist 
of node names and boolean operators, and 3) all its consequents are nets. Once 
in standard form, the temporal logical constraints of the circuit are used to prune 
logtcally disallowed clauses. A clause is logically disallowed when its predicate is 
always false. ■ 

For example, two subnodes connect to make the Bus node of the Three Transistor 
Ram. Two net behavior equations (one for each subnode) exist for the Bus node: 

Bus*,, = A t . Read»(t) => [Bus A], 
N0T(read»(t)) =» [Bus]. 

and 

Bus^i = A t . write t (t) =► [Bus Storage], 
NOT(write 6 (t)) =► [Bus]. 

Merge is applied to the expressions to yield an approximation of the behavior 
equation for the bus node: 

bus^t = Merge (A t . Read 4 (t) => [Bus A], 

N0T(Read»(t)) =► [Bus]., 
A t . Write»(t) =» [Bus Storage], 
NOT(Write»(t)) => [Bus].) 

This equation is rewritten into standard form by forming the cross product of 
the clauses of the conditionals: 

Bus,*, = A t . Read»(t) A Write»(t) =» Merge([Bus A], [Bus Storage]), 
Read»(t) A NOT(Write»(t)) =* Merge([Bus A], [Bus]), 
N0T(Read 4 (t)) A Write»(t) => Merge([Bus], [Bus Storage]), 
N0T(Read»(t)) A NOT(write»(t)) =» Merge([Bus], [Bus]) 

After executing the Merge 's we get 
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Bus*., = A t . Read 4 (t) A Write»(t) => [Bus A Storage], 
Read»(t) A N0T(Write 4 (t)) => [Bus A], 
N0T(Read»(t)) A Write»(t) =► [Bus Storage], 
N0T(Read»(t)) A NOT(Write»(t)) =» [Bus] 

A simplifier now removes logically disallowed clauses. Because Read, and Write. 

r a e r L n vTv sl ? XT"?* asserted ' the *■* clause " logical * disallowed and » 

removed. Note that a clause can be logically disallowed not only because of mutually 
exclude signals, but also for any fixed relationship between signals. For example, 

1 WCre uuT tha * 6ither Read ' 0r Write » were alwa y s «"tad f then the last 
clause would be logically disallowed. 

Besides eliminating logically disallowed clauses, the simplifier also simplifies 
predates to shrink them. For example, because Read, and Write, are mutually 
exclusive, Read, implies N0T( Write.) and vice versa. The result of this simplification 

IS 

Bus*., = A t . Read»(t) => [Bus A], 

Write»(t) => [Bus Storage], 
N0T(Read 4 (t)) A N0T( Write* (t)) =► [Bus]. 

Figure 8.1 shows the result of applying Algorithm MERGE NET EXPRESSIONS 
to all the nodes of the Three Transistor RAM. 

8.2.3 Expanding Nets 

Merging only solves half the problem of generating equations. Nets which span 
across many devices (e.g., from the ground node to the Bus node of the Three 
Trustor RAM) must be found. The generation of behavior equations is com- 
pleted by iteratively applying a simple expansion transformation to each node. The 
expansion transformation expands the -boundaries" of the possible nets of the node 
to include adjacent nets. 

The expansion transformation replaces a chosen node Y in a net N by the ex- 
pression for Y ,. Th» extends N to include the possible-nets of Y. The replacement 
can result in the original net N being replaced by multiple nete. The replacement 
is very similar to the merging of nodes discussed above. 
Algorithm EXPAND NET BEHAVIOR EQUATIONS- 
Inputs: The approximate net behavior equations for a circuit C that were created 
Dy Algorithm Merge. 

Outputs: The complete net behavior expressions for C's nodes 
Method: 
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Bus,*, = A t . Read»(t) =» [Bus A], 

Write»(t) => [Bus Storage], 
N0T(Read»(t)) A NOT(write) =► [Bus] 

Storage,^ = A t . Write»(t) =► [Bus Storage], 
NOT(Write»(t)) =► [Storage] 

A-net = A t . Read»(t) A storage t (t)^ [Gnd A Bus], 

Read»(t) A NOT(storage»(t)) =► [A Bus], 
N0T(read»(t)) A storage t (t) => [Gnd A], 
N0T(read t (t)) A NOT(storage t (t)) =► [A] 

Read^t = A t . [read] 

Write^ = A t . [write] 



Table 8.1: Equations describing the net behavior of Three Transistor RAM after 
merging. These are not the final equations. Not all possible nets have been vener- 
ated. 



For the net behavior expression EX of each equation do 
Repeat 

Choose some net N of EX 

Choose some node Y in the N that has not been chosen before. 

Replace N by (Merge N Y*,,). 

Rewrite EX back to standard form 

Eliminate disallowed clauses. 
Until closure is reached (i.e., nets stop expanding). ■ 

For example, consider Bus,., of Table 8.1. Choosing to expand node A in this 
expression results in: 

Bus„, t = A t . Read»(t) A storage 4 (t) => [Bus A Gnd], 
Read 6 (t) A NOT(Storage t (t)) => [Bus A], 
Write»(t) =► [Bus Storage], 
N0T(Read»(t)) A NOT(Write»(t)) =► [Bus] 

Applying the transformation again for any other nodes in the possible nets of 
Bus results in no change, so this is the final, and correct, behavior expression for 
the Bus node. Repeating the expansion for the other nodes yields the final set of 
behavior expressions for the Three Transistor RAM Table 8.2. Because the A node 
is a connection node its behavior equation is not computed. 
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Bn Snet = A t . Read t (t) A Storage 4 (t) => [Bus A Gnd], 
Read 4 (t) A NOT(Storage 4 (t)) =► [Bus A], 
Write 6 (t) =► [Bus Storage], 
N0T(Read t (t)) A NOT(Write t (t)) => [Bus] 

Storage^, = A t . Write»(t) =» [Bus Storage], 
NOT(Write»(t)) =► [Storage] 

Read^t = A t . [Read] 

Writer = A t . [Write] 



Table 8.2: Equations describing the behavior of Three Transistor RAM. The A 
node ,s not represented because, as a connection node, its behavior expression is 
not computed. 



(As described net expansion is a very costly operation because the same nets 

Wl JL f T*l many timCS - Silka PitheCUS carefull y kee P s tra <* of which mergings 
need to be done to minimize the number of mergings.) 
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Chapter 9 

Net Behavior to Digital Behavior 

As expired in Chapter 6, Silica Pithecus abstracts a circuit's digital behavior 
directly from the circuit's net behavior. The translation from net behavior to sig- 
nal behavior and then signal behavior to digital behavior only occurs subliminally. 
Nonetheless, we will act as if the translation did occur: doing so simplifies the 
exposition. 

In the examples the outputs of a circuit's signal behavior applied to the circuit's 

inputs were abstracted. In this chapter (a representation of) the signal behavior 

tself is abstracted. Applying this abstraction to some inputs i yields the same 

result as abstracting the outputs of the original signal behavior applied to ». That 

ABS?B Tn ^ wer \ com P utin « * 5 • ±BS(B s (Dcsign)(i)), we now compute 
±BS(B s (Design))(t). In the second expression ABS(B S (Design)) is applied to t 
We have made ABS polymorphic; here ABS is operating on functions, ratner tlan on 
signals. Signal behavior itself is abstracted by constant folding the (representation of 
the) signal abstraction function, ABS 5 ^ r , over the (representation of the) circuit's 
nrbehavTw° r * chapter shows how ^S(B S (Design)) is derived from Design's 

The formal notation for describing the abstracted signal behavior of a circuit 
with N inputs (which are signals) and M outputs (which are digital values) is 

A 3 . b where o x = /i(3,o), ...,o m = / m (3,d). 

The formal notation is rarely used. Instead, the equational part will be given; the 
ambda bound signals and return values will be left implicit. An example appears 
in Table 9.1, which shows the abstracted behavior of the Inverting Latch 
Conceptually, the generation of ABS(B S (Design)) is a three step process: 

1. Constraints are generated from Design's net behavior, 

2. B s (Design) is generated, 

3. B s (Design) is abstracted to yield ABS(B s (Design)). 
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During the first step flow and timing constraints are generated. During the third 
step threshold constraints are generated, and charge sharing bugs and ratio bugs 
are found and reported. In the implementation the steps 2 and 3 are intertwined 
to minimize the amount of detail of B s (Design) which is generated. 

♦i. J^ d ? iU \ ValU6 at n ° de X is den0ted X »/- We retract the ««H" statement 
that the digital values are 0, 1, and float} Instead, four digital values, called driven 
1, driven 0, floating 1, and floating 0, are used. Digital values have two attributes, a 
boolean attribute and a floating attribute. Each attribute has two possible values 
which gives rise to the four digital values. A digital value X*, is denoted <X»,X,> 

tT^l d r n0teS the b °° lean attribute ofX^nd X, denotes the floating attribute 
of X. The four digital values are denoted <1,D>, <0,D>, <1,F>, and <0,F> 

Two functions, B and F, are used to project the different parts of digital values 
B projects the boolean part, and F projects the floating part. 

The greater precision of the four value scheme is required. The three value 
scheme (0, 1, and float), though adequate for describing intended digital behavior, 
is inadequate as a target space for abstraction. The problem is that a signal may 
either be used for its boolean attribute or for its floating attribute. The abstraction 
function can't know which attribute is desired by the designer and must return both 
attributes. The comparator is responsible for matching abstracted attributes with 
the designer's intentions. A 1 intended by the designer is matched by either <1,D> 
or <1,F>. Similarly, a float intended by the designer is matched by either <0,F> 
or <1,F>. ' 

Threshold constraints dictate that certain signals cannot suffer threshold drops 
A signal that has suffered a threshold drop is called degraded. Threshold constraints 
ensure that ratios of nMOS gates will yield logically valid voltages. They also ensure 
that voltage levels are aren't made invalid by passing through pass transistors gated 
by degraded signals. The example of Chapter 3 indicated that threshold constraints 
were generated after B s (Design) was generated. This is not the case. Rather 
threshold constraints are generated as B s (Design) is generated. 

Example: Inverting Latch 

As a running example, this chapter shows how ABS(S 5 [Inverting Latch)) (Ta- 
ble 9.1) is derived from the Inverting Latch's net behavior. The net behavior of the 
Inverting Latch (Figure 1.3) is 

Out„, t = A t . S t (t) -+ [Vdd, Gnd, Out], 
N0T(S»(t)) -+ [Vdd, Out] 
IiW = A t . Latch»(t) -* [In, S], 
N0T(Latc h»(t)) - [In] 

^he digital specification language still uses just the three values. But Silica Pithecus's internal 
representations use the four value scheme. 
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Out», = B(S 4/ ) -* <0,D> 

-BCSj,)) - <1,D>. 

In t/ = ABS(In,) 

S»/ = B(Latch 4/ ) - ABS(In,), 

-iB(Latch 4/ ) - ABS(S,). 

Latch*/ = ABS (Latch,) 



Table 9.1: ABS(B s (Inverting Latch)). X if denotes the digital behavior of AT. 



are: 



Smt = A t . Latch»(t) — [In, S], 
NOT(Latch»(t)) - [S] 
Latclw = A t . [Latch]. 



The contracts issued while generating the above digital behavior 

1. falls(Latch,) =► falls-first(Latch,,In.) 

2. control(Latch.) 

3. Latch* =► ov«rpowers([In] /n , [S] s ) 

4. no-drop(Latch,) 

(The generation of the first three constraints has been discussed (Chapters 4 and 5) 
This chapter discusses generating the fourth constraint.) 

Creating ABS{B s (Design)) and generating theshold constraints is conceptually 
simple. Starting from net behavior, each transistor in a net is replaced by its full 
model. If there are N transistors in a net this generates 3* detailed nets. A detailed 
net is a net where each transistor has been replaced by the resistor and threshold 
drop device which model one of the transistor's operating regions (Figure 9.1 shows 
a detailed net). Each detailed net is then analysed to produce a combination of 

i n? t ^ nt J rain ?' ab8tracted volta « e Ic ™fe> ^d reports of actual design errors. 
Although 3 detailed nets are theoretically required, only about 2JV detailed nets 
actually need to be enumerated. 

This chapter has two sections. The first section shows the analysis of detailed 
nets. The second section presents the enumeration method for detailed nets which 
minimizes the number of detailed nets generated. 
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Figure 9.1: A Detailed Net 



9.1 Analyzing Detailed Nets 

During analysis each net spawns many detailed nets. The detailed nets are analysed 
to predict and abstract the voltage at a given node in the detailed net. When valid 
voltages occur they are abstracted to either or 1. When an invalid voltage occurs 
either a threshold constraint is generated, a charge sharing bug is reported, or a 
threshold bug is reported. 2 

A signal value is the value of a signal at some particular time. A signal value 
has two attributes, strength and voltage. Once all constraints have been issued and 
design errors caught, all signals are abstractable. Therefore no errors are reported 
when abstracting a signal and all that is left for the abstraction function to do is 
turn a signal's final value into a digital value. The following function does this. 
Algorithm STD (Signal Value to Digital Value): 
Inputs: A signal value SV 
Outputs: A digital Value. 
Method: 

If SV is driven let strength be "D" else let it be *F." 
If V > 3.5 then return <l,strength> 
else if V < 1.5 then return <0,strength>. 

We now discuss determining and abstracting the voltage at a given node in a 
detailed net. When the final voltage of a signal S can't be determined (because 

'This iB overly conservative. If the designer depends only on the signal being nndrhren and not on 
tne signal s boolean value, then no error should be generated. Silica Pithecus could be changed to 
return a value denoting an invalid voltage. Then only when the designer depended on the value 
would an error be generated. 
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the voltage comes from stored charge rather than from gates), it is known, because 
ot constraints and assumptions of valid inputs, that the final voltage will be valid 
Abstracting such a signal yields the symbolic result ABS(S). 

There are three cases to consider depending on the nodes in the detailed net 

Net contains driven nodes. The driven nodes determine the final values of all 
the undriven nodes in the net. With one exception, nets may contain only 
one driven node. The exception is that a net may contain both Vdd and Gnd 
When a net contains both Vdd and Gnd, the network is transformed into 
an equivalent voltage divider using Thevenin equivalents. (Examples appear 
below.) K 

Net contains no driven or input nodes. There are two cases to consider based 

on whether there is some node N whose capacitance overpowers the rest of the 

net. When N exists, the result of abstraction is the symbolic result ABS(N,). 

When N does not exist, data dependent methods must be used to determine 

if charge sharing will result in valid logic levels. These methods show that 

enough nodes have the same logical value such that the net settles to this 

logical value. Silica Pithecus employs a simple heuristic to determine whether 

enough nodes will have the same logical value. It first determines the phase 

at which the net is activated (e.g., fa or *,).» It then determines the values 

of the nodes at the end of the previous phase. If enough of the nodes have 

the same value then that value is used. When not enough are the same, an 

error is generated. 

Net contains an input node /. Flow constraints guarantee that / is the domi- 
nant node. The voltage of a node other than / in net cannot be determined, 

V™,t V^ aCtl ° n ° f a Signal an ^ here in net is guaranteed to be the same 
as ABS(I.). (Note that the term "input node" refers to nodes declared to be 
the inputs of circuits. "Input node" does not refer to driven nodes, as it does 
m other systems. There is no guarantee that an input node will be connected 
to a driven node.) 

9.2 Enumerating Detailed Nets 

A conducting transistor has three regions: full conductance (gate voltage of 5 volts) 
partial conductance (gate voltage above 3.5 volts), and unknown conductance (gate 
voltage between 1.5 and 3.5 volt s). Theoretically, to predict the full behavior of 

3 On the next revision of this document I will explain where 4i and * 3 came from. 
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a given net, the net must be instantiated with all ranges of its transistors' behav- 
iors. Therefore predicting the behavior of a net theoretically requires generating 3" 
detailed nets where N is the number of transistors in the net. 

However, by carefully enumerating the nets and by being conservative, 4 only 
2N detailed nets need be generated. There are two key observations. First, there 
is no need to create detailed nets where a transistor is in the unknown conductance 
region. By implicitly constraining all signals which gate transistors to have valid 
voltages it is ensured that transistors never operate in this region. These implicit 
constraints are checked as part of verification. This strategy reduces the theoretical 
number of required detailed nets to 2 N . 

Second, by judiciously choosing the order in which nets are enumerated, it is 

possible to set the operating region of transistor to just one of the two remaining 

regions it could be in. The region is set the first time the transistor is encountered. 

When a detailed net yields a valid voltage where transistor T is partially conducting 

then the net will yield a valid voltage when T is fully conducting. Therefore there 

is no need to generate the detailed net where T is fully conducting. It is only 

necessary to generate that net when the detailed net yields invalid voltages when T 

is partially conducting. In this case, a threshold constraint is issued to prevent T 

from partially conducting and thenceforth T is always fully conducting. Therefore 

detailed nets where T is partially conducting need never be generated. These two 

strategies together, plus the rule that the possible nets of a node are analysed from 

smallest to largest, allow the analysis routine to generate only a linear number of 

detailed nets. 

[I must mention validifying use of foo» and must mention steadystate logical 
constraints here.] 

Example: Inverting Latch 

As an example we will generate ABS (B s (Inverting Latch)) from Inverting Latch's 
net behavior (Figure 9.2). We will analyze the behavior of each of its nodes in the 
order Latch, In, S, and Out. The result appears in Table 9.1. 

The first node to be analyzed is Latch. It has only one possible net, itself. There- 
fore, the abstraction of Latch's signal behavior is the symbolic result ABS(Latch.) 

The second node to be analyzed is In. It has two possible nets. But because it 
is an input node, generated constraints guaranteed that In is the dominant node of 
all of its possible nets. Therefore the abstraction of its signal behavior is ABS(In.) 

The third node to be analysed is S. It has two possible nets. They must be 
analysed m detail. The smaller net is analysed first. This net is selected when 
voItagetLatch,^)) < 1.5 volts. B ecause the net has just one node 5, the abstrac- 

4 SoThTvSr meaM ' " alWayS * ** the ™ k ° f introducin * a few mor « • ourc «' of fel" negatives 
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Figure 9.2: Inverting Latch's Net Behavior 
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tion of the net's signal at node S is ABS(S,). The first of the two clauses of 5's 
abstracted behavior expression is now generated. It is 

voltagefLatch,^,)) < 1.5 =» ABS(S,). 

The predicate is equivalent to, and replaced by, -iB(Latch*,) to yield 

-B(Latch ft/ ) =» ABS(S,). 

5's other possible net is then analysed. The first detailed net generated uses a 
partially conducting Latch-Gate: 

In 2R 2volts 

w- 



Analyzing this detailed network yields a maximum voltage of 2 volts at S due 
to threshold drops. This is an invalid voltage, so a threshold constraint is slapped 
on Latch.. (This is the fourth, and final, constraint placed on the Inverting Latch.) 
In all future detailed nets this constraint will guarantee Latch-Gate is always fully 
conducting. The detailed net where Latch-Gate is fully conducting is tried next: 



In 1 R 3.5 volts 

O^ — ISI— 



This net has no threshold problems. We employ the flow constraint that requires 
[In] /n overpowers [S] 5 to infer that the abstraction of the signal at S is ABStfn.) 
Therefore, the second clause of 5's abstracted behavior expression is 

voltage(Latch,(*,)) = 5 => ABS(In.) 

which is equivalent to is 

B(Latch 4/ ) => ABS(In.). 
We therefore have 

S», = B(Latch t/ ) - ABS(S,), 
-B(Latch ft/ ) - ABS(In,). 

The last node to be analysed is Out. It has two possible nets. The detailed net 
for the smaller net is 
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4R 

5 volts 
-Out 



tlerifore yieldS * ^ ** ^ ° M *""* ° f ° Ut ' 8 abstracted si * nal beh ^ior is 

B(S 6/ ) =» <1,D>. 
The first detailed net for Out's other possible net is 




2 volts 

Analysis yields 1 volt at Out. Out's other abstracted clause is 

B(S»/) => <0,D>. 

There is no need to generate the other detailed net as it will yield a valid voltage 
when the pulldown is partially conducting. 
We therefore have 

Out t/ = B(S t/ ) -► <0,D> 
-nB(S t/ ) -+ <1,D>. 



9.3 Summary 

This chapter showed how ABS (B s (Design)) was generated from Design's net be- 
hav,or Sihca Pithecus's method for determining the final voltages of nodes in 
detailed nets was given. When invalid voltages are detected Silica Pithecus issues 
an approve threshold constraint, charge sharing bug report, or invalid ratio bug 
report Silica Pithecus generates detailed nets from a node's possible nets. Al- 
though exponentially many detailed nets can be generated for each possible net 
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Chapter 10 
Hierarchical Verification 

t I htT, that d f Pit t the UbIqUity ° f the W ° rd ahie *archical» *» many systems and 
theses, researchers have missed the major idea of hierarchical verification. A ver- 
ifier is a theorem prover, and hierarchical verification is a mechanism for focusing 
the theorem prover. An effect of focusing the theorem prover is vastly increased 

th/S P^e J W emPhaSiZCd ^ effidenCy ^ With ° Ut Standing 

a JttZ f aP r ^ 5 r Cti0nS ' ThC *** SeCti ° n Pre8ents hie ^hical verification as 

y^vI^T^Jl Pr °.° fS - ^ 8eC ° nd -"** di8CUases Barrow ' 8 hierarchical 
venfier Verify. The third section presents the interactions between hierarchical ver- 

h e fZr 7 ltlI ; veI u ? rification - H ^<*ical digital verification is presented in 

L th^ 860 ^ Pr ° blemS WUh WerMchical ^tional verification are discussed 
m tne fifth section. —<«^ 

10.1 Focusing Proofs 

I claim that verification is formally proving that certain predicates about a circuit 

tt~ 7? ^ ™ aM T m Pt0Ver Which pr ° VeS the PW*ca*- «e true (or proves 
hey are false) The predicates can be about physical characteristics of the circuit 

or' W?^, h a . b ° Ut , CleCtriCal Pr0pertieS <«•*» *» out P uts h ™ v ^ voltages), 
or functional properties (e.g., the circuit is a 32 bit adder). In each of these cLes 

when a design is represented solely in term, of the interconnections of its primitive 

without any imposed structure, a theorem prover must wade through a massive 

Wto H l** ™*™?*'™ * P~of. The theorem prover will require a long 
time to derive the proof, if it can find one at all. 

Large, complex designs are created by recursively composing simpler designs 
^ m ° re COm P lex desi « M ' The structure that results can be, and has been, 
exploited * organize* correctness proof. A hierarchical verifier is a method of 
verification that establishes lemmas (subpredicates) about the design, then proves 
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P(Design) 



P< ° 1 > P <~> P(Dn) 

l\ /l\ 

P(011) P(...) P(D1n) P(Dm) P( .. p(Dnm) 

/ |\ I /\ /l\ /|\ 

Figure 10 1: Focusing a Proof. When described hierarchically, a design can be 
represented as tree. The leaves of the tree represent the primitive elements of the 
design and the nodes represent composition. Shared structure occurs when a node 

VkT 1 uJ mOTe , ° nC ° ther n0de ' * ^^Wcal verification, lemmas are 

established at nodes of the tree. These lemmas are used to establish the proof 
either the proof itself or other lemmas higher in the tree. 



the desired predicate from the lemmas. The lemmas are organized around the 
structural components of a design. For some types of verifiers, such as design rule 
checkers, the lemmas can be automatically found (e.g., the inside of this cell is OK) 
For other verifiers such as Verify or Silica Pithecus which are behavioral verifiers, 
the lemmas must be provided by the designer. 

Hierarchical verification is shown pictorially in Figure 10.1. A hierarchical de- 
sign can be represented as a tree where the leaf nodes represent primitives (e.g., 
rectangles transistors, switches, adders) and the nodes represent compositions (eg. 
abutment functional composition) of components. Structure can be shared, a node 

Ca n / \ C ^ ^ ny ° ther nodeS ' Whereas a non-hierarchical verifier (hereafter 
called a flat venfier) would reason directly from the primitives and the meaning of 
compositions, a hierarchical verifier proves lemmas about nodes in the tree. These 

ST "V!!? *? prove Iemmas further up in the tree - Fina11 * the lemm ^ «• 

used to verify the design itself. 

For example, when asked to verify an ALU, a hierarchical verifier would first 
verify that the low level cells, such as adder cells and comparator cells are correct, 
then it would prove that arrays of those cells are correct (using the knowledge 
that the celb are correct), then it would prove the ALU itself is correct (using the 
knowledge that the arrays of cells are correct). 

There are three major advantages of hierarchical verification. First, the inter- 
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mediate lemmas may allow a proof to be found where a flat verifier fails to find 
a proof. Second a component's lemmas need only be established once, regardless 
of the number of times the component is used. Third, establishing lemmas causes 
errors to be pinpointed quickly and accurately. 

In regular designs a given component may be used many times. When shared 
structure is used to implement the different instantiations of the component, lem- 
mas need only be established once for it (at the node in the tree which creates the 
component) A flat verifier is forced to implicitly reestablish the lemmas for each 
Zh'kT^ 'opponent. This advantage, only establishing lemmas once, is 

TWi n f7^v 7 ^ ^ Primary contribution ^ hierarchical verification. 
The gam of establishing lemmas only once for a component depends on the regular- 

Z£ K 6 ^ eXtTB ? ely r6gUlar de8ignS With «>*Ponents replicated many 

times there is a large gam, for less regular designs there is less gain. 

Establishing lemmas for components is equivalent to verifying those components. 
Ve fying components before verifying the whole design finds errors incrementally, 
which is extreme y important. Detecting bugs as they occur causes revaluation o 
designs at an early stage. Often a design flaw in a small segment of a design inval 

L wasteful **' Det6Cting ^ ^ ° nly *~ the de8i ^ is co -S 

10.2 Behavioral Verifiers: Verify 

To make these ideas concrete without introducing the complexity of dealing with a 
design's context we will discuss how Verify [Barrow], a hierarchical verifier wcl 
Verify is a monolevel verifier that operates in the digital and arithmetics domains 
tlnZrJ 7 ♦ tW °, inputs ' a 8t ^*^al description of a digital design, and a func- 
tional description (,.«., a program) of the intended behavior of the design. Verify 

posing a™' "? ^ by ^ 8trUCtUral *«»*»« * functioSiy com- 
fnTenll h K T * *? *?" ct ™'* ^ » then compares the derived and 
desert T? **&**». If the behaviors are equivalent, the structural 
lemZ t? ? t Z t0 bC a VaIid im P lementa «on of the intended behavior. The 
exSs itX^d^io" -* ^ IS ^ ^ beWbr ° f ~* ™ 
Verify derives ite power from its method for deriving a structure's behavior. It 

SSE? K I ^ behaVi ° ra (the IemmaS ^ ° f a *™*«* parts rather than the 

derived behavior of the parts. The resulting behavioral description is far easier to 
manipulate and reason about than the behavioral description that would have been 
otherwise generated. For example, once an n-bit adder is verified as an adder, its 

oi £T?k 8 C anthmetk 8Um ° f itS inpUtS ' rather tha » * implex boolean formula 
of n-bit boolean vectors. 
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10.3 Hierarchical Multilevel Verifiers: The Prob- 
lem of Context 

(When discussing hierarchical multilevel verifiers, there is a potential confusion to 

diffeTnff , h r: are - two , 1 r archies ' the *""*■* **™** *** *■*» t ° 

t how r ?r° T t l deSCri P tion ' and th * *""*nrf hierarchy which refers 

to how a design ,s put together. When just the word "hierarchy" is used the intended 
hierarchy should be clear from context.) 

Monolevel verifiers assume a design's behavior to be solely a function of the 
interconnection of the design's parts, and not a function of the context of the de- 
sign This assumption cannot be made for multilevel verifiers. Employing partial 
abstraction functions and specialized behaviors requires considering a design W 
o^: n W 7f ng itS , behaVi0n b ~« a deS * ner 0n * -res a bout g a n s S u C bset 
imptrtar * * *** "" """* that ** rise to that subset is 

Nonetheless, just as hierarchical monolevel verifiers use the intended behavior 
of components when proving a circuit exhibits a given behavior, we would like to 
hL ab't r P ,f ° rmn J? multilevel verification. Doing so is much more efficient 
than abstracting the combination of the circuit's signal behaviors. How hierarchical 
multilevel verifiers operate will be described both graphically and algebraically 

The relationship between multilevel verification and hierarchical multilevel ver- 
ification is shown graphically in Figure 10.2. In this figure the design's concrete 
behavior is on the left and its intended abstract behavior is on the right. The stru ! 

Th ftS I?* nUtl ™ the , t0 P "* the be *avioral representation on the bottom. 
The task is to verify the top left corner (the structurally represented design where 
the concrete behaviors of the components are known) against the lower right hand 

tToe e r r f rm £Tt **"* *?"** * *"" "*****• There - two wa^s 
to perform this task corresponding to paths A -> B -+ C (flat verification) and 

^vfor^hl wkT^ V : nfiCati ° n) * FUt verification fi "* d^ves the concrete 
behavior of the whole from its parts, then abstracts this behavior and compares it 

Lent? I ^ u ehaVi0r ' Hierarchi <*l verification first verifies the corn- 

et™ :1 h * n , COmP< Tu hC com P° nent8 ' in ^nded abstract behaviors to derive the 

La ZTS ha Ti° f u he Wh ° le de8ign * This derived descri P tion » then compared 
against the intended abstract behavior of the entire design. 

This can be stated algebraically using the function compose, which forms the 
composition of its operands. 1 Flat verification shows that 

ABS ( C0 "*P<«««,»(5eon(A), . . . ,B e<m (£> n ))(?)) 



7^ ^ttt^ . f T aI ' f ° r * f ° rmal treatment ° f the <"»*"< *— "• lG-*-U. <* 
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Multilevel Verification 



■► Bib( Design) 
C 



dfli lit fi ♦ ^f^Pbetween multilevel verification and hierarchical mul- 
tilevel verification. In multilevel verification (path A - B - C) the concrete 

th abs^ ^kT • ° nentS J? C ° mP08ed ' the fe8Ulting behavior ^racted, then 
the abstracted behavior is validated against the intended behavior. In hierarchical 

multileve verification (path A - D -, C) the structure's parts are verified, the 

the parts' intended abstract behaviors are composed, and the resulting behavior 

validated against the intended abstract behavior of the whole. 
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Bi B {Design){ABS(i)). 
Hierarchical verification shows that 

compose ab .(B IB (D l ) B tB {D n )) = B IB (Design). 

Hierarchical verification is valid only if it yields the same result as flat verification 
Thai i^only^ A -* B -* CandA ^ D -* C tf Figure 10.2 yield the same result). 

ABSfcompewe^B^A), • • . , B eon (D n )) (?)) 



compose^iBjeiDx), . . .,B IB {D n )){ABS(t)). 

We claim that they are equivalent when the satisfaction of Design's constraints 
imply the satisfaction of Design's components' constraints. 

nn We tV 0t f0rmall3 [ Pr ° Ve tWs daim ' to do so would «**• P^g compose 
statTml TV ^w u InSte f\ We 8ketch a P r °of «* * ^pHfied version o/the 
statement. This sketch uses the function UNABS. UNABS takes an element of 

Xrl^A ?T ^ f etUmS ■* eIement 0f the concrete domain - The element 
UN^srlTs 3^ n k 1<>n ? M VX e *MABS(UNABS(*)) = X). In the sketch 
UNABS(ABS(*)) will be substituted for X. In general, this is not a valid substi- 
ution. We guarantee, however, that any unabstracted value is later abstracted so 
that no information is lost. 

In the sketch Design has N components, A through D n . We begin with the 
abstraction of the compositions of the concrete behavior of the components: 

ABSicompose^B^iDt), . . . , B eon (D n ){t)). 
The outputs of each component are abstracted then unabstracted: 
ABS(compose eon (\ j . VUABS(ABS(B eon {D l ) (}))), 
A /. UNABS(ABS(B eon (I? n )(3)))) 

Each occurrence of ABS(£ aA ,(A)0)) is replaced by A 's intended abstract behavior. 
This replacement is only valid when the constraints on D< are satisfied. For this 
reason, the satisfaction of the constraints on Design together with the physical 
construction of Design must imply the satisfaction of the constraints on each D- 
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Figure 10.3: 
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AB^ om 4.°t( fl5 ( Bl ),i^,)( S) r' ,M ^ (B ' i(l>,) ' B " (c ' ))ABs(s) from 



ABS( com pow eon (A j . UNABS^p^ABStf))), 
• . . , 

A j . UNABS(S 7fl (£> n )(ABS(3)))) 

Z^r^TTV { ABS ( UNABS ^) «e now eliminated. This step has two 
ma or results First, all occurrences of UNABS vanish. Also, the only remaining 

3ST Thi ^ thOSe ° n th i '^^ t0 the **» *"* and -t o™ n g 
no mLeT BS \ ° C . CUrrences can be c °»"ted «xd moved onto I. Second, because 

ZZ7X T? ? "* intCrnaI Une8 ' abstract beha ™ » being composed 

ABS yieM n * ^^ ^ eliminatioM <* ™ABS and trans^erenc^f 

compose^iBjaiDx), . . .,B IB (D n ))(ABS{i)), 
u^as™ 8 Pr ° 0f Sk6tCh l8 8h ° Wn t^V^y for * ^o component design in Fig- 
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L2 




Out 



Figure 10.4: A Shift Cell. This circuit is made of two Inverting Latches. 



10.4 An Example of Hierarchical Digital Verifi- 
cation 

fFi^TS^u hie : ar ^ cal T di 8 i ^ verification' we will show how a Shift Cell 

v! TZ ] ^ ° Ut ° f tW ° InVefting LatcheS is verified ' ( An <»«**" of the 
verification of this circuit was shown in Chapter 1.) 

The intended digital behavior of the Shift Cell is 

(df (SHIFT-CELL si s2) 

(let ((Left (INVERTING-LATCH si)) 

(Right (INVERTING-LATCH s2))) 
(lambda (in 11 12) 

(Right (Left in 11) 12)))) 

This digital specification says that the behavior of a Shift Cell is equivalent to two 
inverting latches, one feeding the other. 

thafLr^rrV ^ T^ fOT ^ 8hift Cdl: tnu *«(Ll., L2.). It declares 

T2 >«< *a ™' *" mUtUaUy eXCluSive ' That »» at no tim « are both LI. and 
L2. asserted. This constraint will be used to satisfy some of the Shift Cell's parts' 
constraints. 

The verification condition is shown -graphically" in Figure 10.5. In this figure 
noun* are the constraints derived during verification and INVERTING LATCH 
represents the intended digital behavior of the Inverting Latch. The verification 
condition is shown graphically rather than algebraically to stress that, in Silica Pi- 
thecus, the comparison of abstrac ted behaviors and intended abstract behavior of 

'havTtd dJS rf^i "u tikVel VerifiCaki ° n WhCTe 8i « nal beh »™ - th « terete be- 
fiavior and digital behavior u the abstract behavior. 



10.4. AN EXAMPLE OF HIERARCHICAL DIGITAL VERIFICATION 
V 'v L1 S . 12, S1,, S2 } ,^mu«ox(U,. 12^^ L1> L2,, Sl„ S2y *-^ X » Y} 
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Figure 10.5: The Verification Condition for the Shift Cell. P found are the constraints 

bZ fT r fiCati ° n - INVERTING L ATCH represents the intended digita 

behavior of the Inverting Latch. 6 



rnfouTstts 10116 StFUCtUrally (C/ ' Chapter 6 )- The verification condition is proved 

ht*S ^T* ^ C ° M !? intS which *»<>" ^(/nvertm^ £«*<*) to be replaced 
by B IB (Inverttng Latch). These are generated by mapping the constraints of each 

ofT/tTr ° f th % InVertin « La J ch - Ma PP«8 of constraints £ similar to the mapPmg 
of net behaviors Sect™ 8.2.1). Table 10.1 shows the generated constraints. (These 

in F^re l.t) ^^^ ** *"* ««**«* of the **■*»• Latch Ihown 

Step 2: Process the constraints. Each constraint is either accepted, rejected, or 
propagated. Chapter 11 discusses processing constraints. 

Accepted Constraints: Three of the above nine constraints are satisfied: 

• L2» A-,S1» => overpowers([Gnd, C] c , [S2] 53 ) 

• L2» A Sl» =► overpower«([Gnd, Vdd, C] c , (S2] 52 ) 

• falls(L2») =► falls-first(L2„ C,). 
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Mapped Constraints for Left 

control(Ll.) 

no-drop(Ll.) 

LH => overpowers([In] /n , [Sl] 51 ) 



Mapped Constraints for Righ t 

control(L2.) 

no-drop(L2.) 



L2» A--S1 4 => overpowers([Gnd, C] c , (S2] 52 ) 
. ., /T , , L2 » AS1 » =► overpow«rs([Gnd, Vdd, C]„, [S2l„J 

falls(LU) => fall.-llmfLl.Jn.) | fall,(L2,) => l^lLlirst^t) ' 



Table 10.1: Mapped Constraints of the Shift Cell 



The first two are satisfied because Gnd and Vdd have infinite strength whereas 
52 has finite strength. The third constraint is satisfied because the logical con- 
straint tautex(Ll„ L2.) with the constraints controlfLl. ) and control(L2 ) 
ensure that L2. falls before C. can change. 

Rejected Constraints: None of the constraints are rejected, U., shown to not 
hold. 

Propagated Constraints: The remaining six constraints are propagated to be- 
come the P found of the proof: 

• Ll 4 =» overpowers([In] /n , [Sl] 51 ) 

• control(Ll.) 

• control (L2.) 

• no-drop(Ll.) 

• no-drop(L2.) 

• falls(Ll») =» falls-first(Ll„ In.) 

When the Shift Cell is used these constraints are processed. Constraints are 
passed up the structural hierarchy until they are satisfied or rejected. 

Step 3: Replace each occurrence of B s (Inverting Latch) by INVERTING LATCH 
and slide ABS from the output to the inputs. 

Step 4: Compare the two structures. They are the same, so the it is concluded 
q1d T mPUtS '• ABS(i?5 ( Shift Cell X f )) = *»(Shift Cell)(ABS(f)), 
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10.5 Problems with Hierarchical Functional Ver- 
ification 

In e r/r T* y . ? tra v problemsS in Performing hierarchical functional verification 

tTon of tl V 7 f/ traCt ^r^ (< ^* SetS ' nUmberS ' addresses > or a collec 
rZ r* ?**! ° f functlonal verification. One of the additional difficulties is 
compound data Compound data prevents a component's concrete behavior from 
being replaced by its intended behavior. 

10.5.1 Compound Data 

7b££??* ab8t ^ b6haVi0r ° f * d68ign by ^P™** ** components' intended 

fts owf^ Tr; T1US T POWible beCaU8e eVery 0Ut P ut rf «* c ^Ponent had 

a str^htf ^ IT* F ° r drCUit8 ** gang6d ° Ut P uts < 8Uch ** vect °« of bits) 

fails substitution of intended abstract behavior for concrete behavior 

Thi^^K' -T^,* ?" bit adder which «*«nis a 4-bit result (Figure 10.6). 
This adder is built out of the adder cell verified in Chapter 3 (Figure 3.3). We 
proved that the boolean and arithmetic behaviors of the adder cell were rela ed by 
the equation «*»«- uy 

Vies. {Boolean(i u i 2 , » 3 ) => 

ABS(sum(* 1 , t„ $ 8 )) + 2ABS(carry(, 1 , ,*,, ,",)) 

= ABS(tt ) + ABS(t,) + ABS(«,)}. 

*tZ?*? ^ ^^ *?* ^ the ^^^ * ^.vioc. a. lemma.. Often what i. important 
8 trn^ ur. r Ce t U *f "^l"*** 1 *"*™ ""^vm* »• behavior. When thi. mathemaVkal 
reader is referred to [BarrowJ for a ducastion of thi* problem. 
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(This equation will be used as a lemma in the verification of the 3-bit adder.) The 
difficulty is that neither sum nor carry can be replaced by some function solely of 
the abstracted inputs to the adder. Either must be replaced in terms of the other. 
The intended functional behavior 4 of the 3-bit adder is 

B IB (3-bit Adder) = A a b . a + b. 

Th^r\ ge uT e itS C ° u Cret \ b6haVi0r fr ° m ite "peats' concrete behaviors.' 
tend^W VkT 01 ,S th r ab8tracted - When comparing the abstracted and in- 

~ a ^mtTne^tsaT VerifiCati ° n ^^ * *" ^ ^ ^ ^ *"*« 

behLt c o7r P \rtr r of the 3 - bit adder ' derived by composing the ™- 

B B . (Adder Cell) = 
A [A , A u A 2 , A s ] [B , B u B 2 , S 3 ] . 
[Sum(A , B 0t false), 
5um(Ai, B lt Carry(A , B , false)) 
5um(,4,, B 2 , Carry(A l ,B 1 , Carry{A , B Qt false))) 
^<"ry(A 2 , B 2 , Carry(A u B x , Carry{A , B 0t false)))]. 

iJnuL^Tf 16 "Tl^T^ Restructuring of formal parameters. This function's 
Xl) VeCt0r8 ' De8trUCtUring ™ mea «* bit in *• ^Put 

The abstraction of the adder's concrete behavior is 

2U™ ( c ar 7- ( * 2 >. ji ' Carr ^>*> Ca "ydoJo, t als.))))+ 
oiVrc ^ Um,J '^'^ arr J'*i'^. C, ^y(»o,jb,fals.)))) + 
2 ABS^um^!,^, Carry , ,j ,f alse)))+ 
2°ABS(5«m(, , J b, false)). 

f^^l + aA^^ 1 ?!!?.^ T5 ° f ^ abstraction of ** ^puts, namely 
(2 ABS(, 2 ) + 2ABS(t.) + ABS(io)) + (2 J ABS(j 2 ) + 2ABSU) + ABSfjb)). 
Therefore, the verification condition to be proved is 

v «i t»6B.{5oo/eon(i) => 

l A**S{Sum{t 2 , ft, Carryiti,^, C arry (i ,j , f alse))))+ 

^K? i'*"^? " fP™?* what do ~ *+* mean? Fortunately, the adder's output vector is 
one bit longer than the adder's input vector, so that the normal meaning of + is reused Had 

oe^eLl? TH' VeCt °[ bMn th * 1MM kD * th ' *« n " + ' "»* »<* *»ve betn uS Out" must 
^be careful to not fall mto the trap of using standard operator* in non-standard wayT 

8 I find it hard to say whether flat verification or hierarchical verification is being performed It 
start, out a. flat verification, but, by using lemmas, start, to look like hierarchkal veStbn 
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2 1 ABS(Sum(x 1 ,y 1 ,Carry(t' ,.to,fals«)))+ 
2°ABS(5um(t , jo, false)) 



2 J ABS(, 2 ) + 2ABS(tO + ABS(i ) + 2 2 ABS^) + 2ABSft) + ABS(jb). 

There are three alternatives. The first is to expand out the calls to Sum and 
Carry and use exhaustive methods to prove the equivalence. Although this strategy 
would work for the 3-bit adder, it fails as adders get larger. The second alternative 
is to replace the abstraction of the concrete behaviors of with the intended behavior 
of the outputs But as mentioned earlier, this alternatives fails because the outputs 
are interrelated and are not eliminated by this approach. The third alternative is 
to be intelligent" about which of Sum and Carry to eliminate. 

We will rewrite the verification condition of the adder cell as 

ABS(0um(* lt t 3 ,ts)) = 

ABS(ij) + ABS(t.) + ABS(»,) - 2ABS(earry(, 1 ,,„,' 8 )). 

This equation is used to eliminate the Sums from the verification condition of the 
3- bit adder to yield 

8ABS(Carry(t„ ji, Carry(i u j u Carry(i Q J Q , false))))+ 
^2!! , ' ,) + ? ABS(ji) + 4ABS ( carr y(»'»^.^»-y(«o,jb,false)))- 

8ABS(carry(i,,^,carry(i ll< h,eorry(ib,jto,f«lM))))+ 
2ABS(»0 + 2ABSU) + 2ABS(carry(,o, Jb, f •1m))- 
4ABS(carry(t 1 , j u carry(i ,j , f alse)))+ 
ABS(*o) + ABS(jo) + ABS(false) - 2 ABS (carry (i Q J Q , false)). 



4ABS(t 2 ) + 2ABS(,- 1 ) + ABS(t ) + 4ABS&) + 2ABSfo) + ABS( Jo ). 
This is equivalent to 

4ABS(i,) + 4ABS(j 2 ) 

2ABS(»!) + 2ABS(yx) 

ABS(t ) + ABS(jb) + 

4ABSft) + 2ABS(, 1 ) + ABS(i ) + 4ABS(j>) + 2ABSfo) + ABSfo) , 
which is true. The 3-bit adder is therefore correct. 

^ (T ^ 8 ^ Pl t Sh ° WS that verif y m « a 8i mple arithmetic unit requires some 
thought. With the right approach, (i.e., eliminating Sum) the proof is simple, 
without it the proof is considerably more difficult. Because of the thought required, 
not all verifiers do this proof algebraically. For example, Verify [Barrow] does this 
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proof structurally* This example is indicative of validation at the functional level: 
otten nontnvial theorem proving must be done.) 



6 Si k r Wge ° f the re P re8entati ° n ° f DUmbe " " Vecto ™ of boolean « to •** ^e proof: 
it » hardwu-ed to recognue predetermined structures as correct implementation of adder,. 



Chapter 11 
Constraints 



Silica Pithecus's constraint system is the key to Silica Pithecus's hierarchical opera- 
turn, and therefore the key to Silica Pithecus's speed. Constraints direct a circuit's 
analysis. They change the nature of analysis from "what does the circuit do?" to 
does the circuit do the correct specific thing?" (Such as "do signals flow in right 
direction here?" or "does signal A fall before signal B?") Such questions are fo- 
cused and efficient to answer, whereas "what does this circuit do?" is unfocused 
and inefficient to answer. 

Each type of constraint has it own special theorem prover, called a handler 
for proving instances of the constraint are satisfied. The handlers for logical and 
threshold constraints are algorithmic and will always get the right answer when 
they terminate. The handler for flow constraints is heuristic. It runs fast and 
works for nearly all circuits. The handler for timing constraints (stable-after and 
falls-first constraints) is heuristic and fails for circuits which rely on races. The 
heuristic handlers only generate false negatives when the fail, they never generate 
false positives. 

Constraints are mapped from the level of the component they are on to the level 
of the design being verified. Constraint mapping mirrors net behavior mapping 
which was presented in section 8.2.1: nodes and signals are renamed to use names 
local to the design. Constraint mapping will not be explicitly presented. Examples 
of constraint mapping appeared in section 10.4. 

Each constraint is either accepted, rejected, or propagated. A constraint is ac- 
cepted once it is satisfied (shown to hold). A constraint is rejected when it is shown 
not to hold. Rejected constraints are returned to the designer. A constraint is 
propagated when it is neither accepted nor rejected. Propagated constraints are 
attached to the circuit being verified. The propagated constraints will be processed 
when the circuit is used as a component in a larger circuit. 

This chapter discusses each type of constraint in turn. 
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11.1 Logical Constraints 

The two types of logical constraints are steady state logical constraints and tempo- 
ral logical constraints. Steady state logical constraints predicate boolean relations 
between the final values of signals. 1 Temporal logical constraints predicate boolean 
relations between the values of signals at all points in time. 

A steady state logical constraint is either a signal name, or a boolean combina- 
tion (using -,, A, and V) of steady state logical constraints. 2 When just a signal 
name it used as a steady state logical constraint it asserts that the signal's final 
value is true. Steady state logical constraints correspond to prepositional logic 
Some complex predicates are named. For example, mutex(x, y) is shorthand for 
(->x A ^y) V (-.x A y) V (x A -iy). 

The most commonly used temporal logical constraint is tmutex. tmutexasserts 
that at no time is more than one of its arguments asserted. A special purpose 
method is used to satisfy temporal logical constraints. We require that all signals 
in a tmutex constraint be control signals. Then we show the signals are mutex when 
all the clocks are low and when each clock is high. 

Silica Pithecus does not propagate logical constraints, therefore a design must 
directly satisfy all its components' logical constraints.' It can do this either struc- 
turally or logically. A constraint is structurally satisfied when it is satisfied because 
of the behavior of the components in the design. A constraint is logically satisfied 
when it ,s satisfied because of one the design's logical constraints. For example, 
consider a component C with two inputs x and y and with a steady state logical 
constraint of x V y. Figure 11.1 shows this component used in two different designs 
Design Dl structurally satisfies x Vy (which maps to o V6) because b = ->a) Design 
D2 logically satisfies x V y (which maps to c V d) because c V d is implied by P2's 
logical constraint c. 

Silica Pithecus does not propagate logical constraints because it wants to main- 
tain user level consistency. For reasons previously discussed, Silica Pithecus does 
not generate logical constraints, the user must supply them. Logical constraint 
propagation is similar logical constraint generation: constraints which the designer 
did not explicitly create get automatically created and attached to designs. It 
would be confusing to the user to have Silica Pithecus automatically create some 
constraints but not others. Therefore, Silica Pithecus doesn't propagate logical con- 
straints. (On another note, not p ropagating logical constraints speeds verification 

'To be precise we should say the predicate boolean relation, between the boolean interpretation of 
final values of signal.. In this chapter we won't be careful about making the distinction between 
signal value, and their boolean interpretations. 

'x yHno n t°(aldx ym* "^ P " dkate "' F ° r example ' there » no (*«ftwdlc»te (at-mort-one 
3 A design directly satisfies a constraint when the constraint doesn't need to be propagated. 
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Figure 11.1: Designs must directly satisfy their components' logical constraints. 
Component C s steady state logical constraint, x V y, must be satisfied by any 
design C is m. Design Dl structurally satisfies x V y (which maps to a V 6) because 

~vZ v < 2F ? giCally 8atisfieS X V y < which ^P 8 toeVd ) because c V d is 

implied by £>2's steady state logical constraint e. 



and simplifies the implementation.) 

Silica Pithecus uses a simple predicate calculus theorem prover to satisfy logical 
constraints. The kernel of the theorem prover was taken directly from the Lisp 1 5 
manual [Lisp 1J]. The theorem prover, invoked by the procedure prove, has two 
inputs: the predicate to be proved, and an environment of assertions, prove returns 
true if the predicate can be proved from the assertions, otherwise it returns false. 
lne following algorithm processes steady state logical constraints. 

Algorithm Process Steady State Logical Constraints: 

Inputs: Design D, its components' mapped steady state logical constraints CLC, 

and its own steady state logical constraints LC. 

Outputs: A list of the unsatisfied CLC. 

Method: Label each wire (node) W< between components of D with the boolean 

formula representmg the value on W,. For each CLC* replace each wire (node) 

name with the wire's label to yield a new constraint CLCL If prove(CLC LC) 

returns false add CLC, to the list of unsatisfied steady state logical constraints. 

For example, consider again the designs of Figure 11.1. These designs have their 
wires labelled according to the boolean functions output by components driving 
the wire. Cs mapped steady state logical constraint, a V 6, is satisfied by Dl 
because prove(a V ^a, {}) returns true. Similarly, Cs mapped steady state logical 
constraint, c V d y is satisfied by D2 because prove(c V d, {c}) returns true 
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Figure 11.2: Processing Threshold Constraints 



11.2 Threshold Constraints 

A threshold constraint on a signal is satisfied by showing that every final net com- 
puting the signal yields either a voltage of 5 volts or a voltage 1.5 volts. For example 
consider the output of an inverter A driving the input of a minimally sized inverter 
B (Figure 11.2). Because B is minimally sized, there is a threshold constraint on its 
input. B's mapped constraint is no-drop(Internal). The net behavior of Internal 
is the mapped net behavior of A's Out node. This net behavior is: 



Outnet = A t 



In»(t) -► [Vdd Out Gnd], 
N0T(In»(t)) - [Vdd Out]. 



The first net yields 1 volt, the second yields 5 volts. Therefore the threshold con- 
straint is satisfied. 

(A note on the implementation: Silica Pithecus doesn't check threshold con- 
straints by examining net behaviors during constraint processing. Instead, checking 
whether a node puts out an undegraded signal is done at abstraction time and the 
result remembered. This saves repeated checking that would occur for a gate with 
large fanout.) 



11.3 Flow Constraints 

Mapping flow constraints is complex and expensive, but processing the mapped 
constraints is simple. Each is discussed in turn. 
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Figure 11.3: A Shift Cell 
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We will use the Shift Cell of Chapters 1 and 10 (Figure 11.3) as an example 
of mapping and processing flow constraints. This device has two components, Left 
and Right, which are Inverting Latches. It also has a temporal logical constraint of 
tmutex(Zl,£2). The Inverting Latch has a flow constraint of 

Latch* =* overpowers ([In] /n , (S] 5 ). 

(A note on the implementation: constraint mapping and processing are inter- 
leaved. This prevents extraneous work and extraneous net expansion. Interested 
readers are invited to look at the code.) 

11.3.1 Mapping Flow Constraints 

Flow constraints are mapped in two steps: 

1. Rename the nodes used in the constraints. 

2. Expand nets named in the constraints. 

The first part, renaming, corresponds to what we have been calling mapping for the 
other constraints: names local to the component are replaced with names used by 
the design. The second part, expansion, is complex: it finds all nets which go into 
and out of an input node. When a constraint is expanded, it may turn into multiple 
constraints. (For example, consider the mapped flow constraints in Table 10.1.) 

Renaming Flow Constraints 

A flow constraint is renamed exactly as a net behavior expression is renamed 
(cf. Section 8.2.1). We will show how the flow constraints of the Shift Cell's two 
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components is renamed. The Inverting Latch's flow constraint is 

Latch* => overpowers([In] 7n ,[S] 5 ). 
This is renamed to 

LI, =* overpowera([In] /n ,[(S Left)] (5Lf/t) )) 
for the Left Inverting Latch, and renamed to 

LI, =► overpowers([C] c ,[(S Right) } (SRitht) ) 

for the Right Inverting Latch. The notation (<node-name> <instance-name>) 
is used to name components' internal nodes (ef. Section 6.2). 

Expanding Flow Constraints 

The basic idea is to find the nets computing signals going into an input node, 
and the nets that those signals must drive. Once each set of nets are found, their 
cross-product is found and becomes the mapped constraints. 

For example, consider the Left's output signal. There are two nets which com- 
pute this signal, [Vdd, Out, C], and [Vdd, Gnd, Out, C]. These nets occur on 
l D 7!, and ( S Left )»' ^Pe^ely. There is only one net to be overpowered, 
[(S Right)]. The cross product of the "drivers" with the "drivees" yields the two 
constraints 

• L2, A -.(S Left) t =* overpowers([Vdd, C] C ,[(S Right) ] (SRight) ) 

• L2, A (S Left), =► overpowers([Gnd, Vdd, C] C ,[(S Right) } {SRigKt) ). 

We now discuss the details of expanding flow constraints (i.e., how to locate 
the driver" and and "drivee" nets). Expanding flow constraints is similar to the 
second and third steps (net merging and net expansion) of net behavior generation 
(Chapter 8). Constraint expansion differs in that after merging, certain nodes are 
dropped from nets before expansion to avoid having the expansion include the nets 
the must be overpowered (or must do the overpowering). 

Consider the constraint P =► ov.r ? ovrB(Netl„ 0<ul1 Net2 lfod . 2 ). The following 
rules find the "drivers." 

1. Perform Net Renaming and Merging for node Nodel to yield X. 

2. Delete all nodes from Net2 from all nets of X. 

3. Perform Net Expansion on X. 
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Analogous rules are used to find the "drivees." The cross product of the two net 
behavior expression is then generated. For every possible combination of a clause 
f l - Netl from the "drivers" and a clause P2 - Net2 from the "drivees " the 
constraint P A Pi a P2 - overpowers^l, Net2) is generated. If P a Pi AP2 is 
logically disallowed then the constraint is ignored. 

Using these rules, the following flows constraints of the Shift Cell are the result 
of mapping the flow constraints of the Shift Cell's components: 

Ll t =* overpowera([In] /n ,[(S Left)] (5Wt) ) 

L2» A -n(S Left) t =► overpowers([Vdd, C] c , [(S Right)] (5 ^ ) 

L2» A (S Left), => overpowers([Gnd, Vdd, C] C ,[(S Right)J (5awo ) 

11.3.2 Processing Flow Constraints 

The result of constraint mapping is a set of flow constraints. Each has the form 
overpower.(JVe*l, Nett). Not considering input/output nodes, an overpowers con- 
straint is accepted when the combined strength of the nodes Netl is ten times 
greater than the combined strength of the nodes in Ntt2. Otherwise the constraint 
is rejected and a charge sharing error returned to the designer. 

When either net of a flow constraint contains an I/O node (,-.«., a node that is 
either an input or an output of the circuit being verified) then the constraint may be 
propagated rather than accepted or rejected. Specifically, a flow constraint cannot 
be accepted if the net to be overpowered contains an I/O node, and it cannot be 
rejected if the overpowering net contains an I/O node. 

11.3.3 Another Example: A Faulty Circuit 

As an example of a constraint that cannot be satisfied because of a buggy circuit con- 
sider connecting the Latched Inverter to the Inverting Latch, shown in Figure 11.4. 
The constraint to be mapped is the same as in the previous example: 

Latch* => overpowers ((In] /r ,,[S] 5 ). 
The net behavior of the C node is 

Cn«, = A t . Ll»(t) A In»(t) - [Gnd Vdd C (S left)], 
Ll 6 (t) A^ In t (t) - [Vdd C (S left)], 
- Ll 4 (t) - [CJ. 

Therefore the constraint maps to the following three constraints: 
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Figure 11.4: A Faulty Circuit. The error in this circuit is caught by a rejected flow 
constraint. 



• L2» A Ll» A In* =* overpowers([Gnd Vdd C (S left)] c , [(S Right) ] {SRitht) ). 

• L2» A Ll» A -In. =► overpowers([Vdd C (S left)] c ,'[(S Right) \ {SRight) ). 

• L2» A -LI. =► overpow«r.([C] c , [(S Right) ] {SRigM) ). 

When the last clause is true (i.e., Ll» is falsa and L2» is true), then fCL 
must overpower [(S Right)] (5iK , w) ). Unfortunately, both C and (S Right) have the 
-same capacitance, so this constraint is not satisfied. Silica Pithecus reports this as 
a charge sharing bug. 

Note that had there been a logical constraint of, for example, either (Ll A L2) V 
(-L1 A -L2) or -i(-,£i A £2), then the erring condition would not have arisen, and 
no error message would have been generated. 



Chapter 12 
Future Research 



This research engenders two kinds of future research: extending the theory and 
implementation, and looking at old problems in new ways. 



12.1 Combinatorial Blowup 

The major (pragmatic) deficiency is the brute force nature of the theory. There are 
many common circuits for which the number of possible nets is large. For example 
the output node of a 32-input nor gate has 2» possible different nets. The outputs 
of large PLA s have even more possible nets. To overcome this problem special 
code must be written for gates with large numbers of inputs. This code would only 
generate the minimal number of nets needed to catch ratio and threshold problems. 
Combinatorial blowup also strikes when discharging logical constraints. When 
the inputs to some device comes from a large PLA, discharging the logical con- 
straints can be very expensive. A smarter theorem prover must be employed which 
has heuristics for quickly proving constraints hold. 

I believe that there are only a few general areas where combinatorial problems 
bite and that special case code can be written to solve 95% of the problems. 



12.2 Feedback 

Feedback was completely ignored. Silica Pithecus can detect static feedback. How- 
ever, it does not detect transient feedback. I do not believe that making it detect 
transient feedback is hard, it just hasn't been done. 
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Figure 12.1: Two Three-Transistor RAMS 



12.3 Circuit Timing 

A timing estimator/verifier built on top of Silica Pithecus would be more accu- 
rate and easier to use than other static verifiers such as Crystal [Crystal] or TV 
[TV]. Because the logical structure and signal flow of a circuit is accurately known, 
Heuristic? " " nation t0 "* Wt to avoid aPP~»mations and potentially failing 

For example, a timing system embedded in Silica Pithecus would not need special 
scans or treewalks of the circuit to determining the "direction" of transistors. Other 
timing systems either scan the circuit or use hints from the designer to determine 
the direction of transistors. Crystal uses hints from the designer. Unfortunately, 
these hints are not checked. The hints to Crystal are similar in intent to Silica Pi- 
thecus s logical constraints. Silica Pithecus checks the designer's logical constraints, 
however, and Crystal doesn't check the designer's hints. If the designer gives Crystal 
the wrong hints he will get back the wrong answers. Also, TV's determination of 
transistor directions is not guaranteed to be correct. If the determination is incorrect 
wrong timing results will be obtained. 

What confuses other timing verifiers is not knowing the possible nets of a cir- 
cuit Because Silica Pithecus keeps track of possible nets with a vengeance, timing 
analysis and critical path analysis can be very precise. 

12.4 Capacitance Coupling 

Ignoring capacitive coupling causes an important class of bugs to be ignored and 
prevents an important class of circuits from being verified. 

For example, consider the two three-transistor RAMS in Figure 12.1. The cell 
on the left will work, but the one on the right will not work. It fails due to capacitive 



12.4. CAPACITANCE COUPLING 167 

Ikxitstrap Node 



I 



Input Node | 1 



A „, 01 



Isolation Transistor 



j. | Driven Node (large capacitance) 



Coupling Capacitor -i— 

Figure 12.2: Bootstrap Driver. This device has much faster response and drive than 
expected because of capacitive coupling driving critical nodes high. 



coupling: it is impossible to store a high value on the storage node. Silica Pithecus 
does not detect this bug. 

As an example of a circuit we would like to be able to verify, consider a bootstrap 
driver (Figure 12.2), which is used in time-critical applications. Assume that the 
bootstrap node, driven node, and input node are initially at ground. The driven 
nodes capacitance is much greater than the bootstrap node's capacitance. The 
bootstrap driver operates as follows: 

1. When the input node rises to Vdd the bootstrap node rises with it. The 
driven node does not begin to rise until after the bootstrap node exceeds the 
threshold for Ql. The driven node does not rise as quickly as the bootstrap 
node because of its greater capacitance. 

2. At some point after Ql turns on, the isolation transistor turns off, isolating the 
bootstrap node. The isolation transistor turns off when the bootstrap node 
rises to within a threshold voltage of the input node. The isolation transistor 
will remain off even if the bootstrap node continues to rise. At this time there 
is a voltage differential across the coupling capacitor. 

3. After this point, as the driven node continues to rise the capacitor maintains 
the voltage differential produced above thereby driving the bootstrap node 
even higher. 

4. Because the isolation transistor remains off, the bootstrap node can be driven 
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fairly high. In some configurations it can reach eight volts. 1 

5. As the bootstrap node goes up the voltage on the gate of the pullup goes up 
well beyond five volts thereby allowing the driven node to reach Vdd. 

As a result of this process the driven node rises much faster and higher than 
if the input node were connected directly to the driven node. A system ignoring 
capacitive coupling calculates an incorrect final voltage (two threshold drops below 
Vdd) for the driven node, as well as an incorrect estimate of the time it takes to 
stabilize. 

The bootstrap driver is not a digital circuit according the definition given in 
Chapter 1. According to that definition, a circuit is not digital when the rate of 
change of voltage affects the final state of a circuit. The correct operation of the 
bootstrap driver requires the bootstrap node to rise much faster than the driven 
node. If the driven node rises faster, then there is no "bootstrap" action. 

I don't know how to extend the theory to include bootstrap drivers and similar 
circuits. This research should be done. 

12.5 Multiple Abstraction Functions 

We concentrated on avoiding stored charge and ensuring voltage levels were ade- 
quate. An abstraction was formulated which ensured these two properties. It might 
be the case that more analog-like circuits, such as bootstrap devices and sense am- 
plifiers, could be verified by positing the proper abstraction functions. Ideally, 
representations of circuit behavior could be developed which make invalid signals 
apparent. 

When a system contains multiple abstraction functions the user would have to 
declare which abstraction functions go with which nodes. There might be heuristics 
which allow a system to guess correctly 95% of the time and to otherwise ask the 



user 
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